On Mon, Apr 25, 2022 at 07:19:08PM +0200, Steffen Einsle wrote:
> Hello Everyone,
>
> I have some xen servers I recently tried to update from xen 4.14 to xen 4.16
>
> Everything worked without problem, except for the Windows Server Essentials
> DomUs.
>
> With xen 4.16 those domains crashed (rep
On Mon, Apr 25, 2022 at 12:39:17PM -0400, Daniel P. Smith wrote:
> On 4/25/22 05:44, Roger Pau Monné wrote:
> > On Fri, Apr 22, 2022 at 12:34:57PM -0400, Daniel P. Smith wrote:
> >> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> >> index d5d0792ed4..e71fa3f860 100644
> >> --- a/xen/arch
On Mon, Apr 25, 2022 at 06:56:03PM +0100, Andrew Cooper wrote:
> It turns out that evaluate_nospec() code generation is not safe under Clang.
> Given:
>
> void eval_nospec_test(int x)
> {
> if ( evaluate_nospec(x) )
> asm volatile ("nop #true" ::: "memory");
> else
>
On 25.04.2022 20:07, Andrew Cooper wrote:
> Clang 13 chokes with:
>
> In file included from xsm/flask/flask_op.c:780:
> xsm/flask/flask_op.c:698:33: error: passing 4-byte aligned argument to
> 8-byte aligned parameter 1 of 'flask_ocontext_add' may result in an
> unaligned pointer access [-
On 26.04.2022 01:06, Andrew Cooper wrote:
> In a GNU compatbile makefile, $(LDFLAGS) are passed to $(CC), not $(LD).
I have to admit that I have always been puzzled by this anomaly.
> In a default CentOS 7 build environment, $(LDFLAGS) is set to -Wl,-z,relro,
> which causes the Xen build to explo
Hello,
I can confirm that "msr_relaxed = 1" solves the problem with Server 2019
Essentials crashing.
Am 26.04.2022 um 09:06 schrieb Roger Pau Monné:
On Mon, Apr 25, 2022 at 07:19:08PM +0200, Steffen Einsle wrote:
Hello Everyone,
I have some xen servers I recently tried to update from xen 4.
On Mon, Apr 25, 2022 at 11:24:37AM -0400, Tamas K Lengyel wrote:
> On Mon, Apr 25, 2022 at 10:12 AM Roger Pau Monné wrote:
> >
> > On Wed, Apr 13, 2022 at 09:41:51AM -0400, Tamas K Lengyel wrote:
> > > Allow specify distinct parts of the fork VM to be reset. This is useful
> > > when a
> > > fuzz
Hi,
On 26/04/2022 09:17, Roger Pau Monné wrote:
On Mon, Apr 25, 2022 at 11:24:37AM -0400, Tamas K Lengyel wrote:
On Mon, Apr 25, 2022 at 10:12 AM Roger Pau Monné wrote:
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 84cf52636b..d26a6699fc 100644
--- a/xen/common/vm_event.c
+
On 25.04.2022 20:32, Julien Grall wrote:
> On 25/04/2022 15:13, David Vrabel wrote:
>> On 25/04/2022 14:43, Julien Grall wrote:
>>> On 25/04/2022 14:37, Jan Beulich wrote:
On 25.04.2022 15:34, Julien Grall wrote:
> On 25/04/2022 14:28, David Vrabel wrote:
>> --- a/xen/common/page_alloc
On 23.04.2022 01:07, Andrew Cooper wrote:
> On 22/04/2022 20:43, Daniel P. Smith wrote:
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index 0bf63ffa84..e2ebbc7716 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -120,8 +121,8 @@ static int get_irq_sid(in
On Mon, Apr 25, 2022 at 11:40:11AM -0400, Tamas K Lengyel wrote:
> On Mon, Apr 25, 2022 at 10:41 AM Roger Pau Monné wrote:
> >
> > On Wed, Apr 13, 2022 at 09:41:52AM -0400, Tamas K Lengyel wrote:
> > > Add monitor event that hooks the vmexit handler allowing for both sync and
> > > async monitorin
flight 169728 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 18.04.2022 11:07, Wei Chen wrote:
> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c
> similarity index 71%
> rename from xen/arch/x86/efi/stub.c
> rename to xen/arch/x86/efi/stub-x86.c
> index 9984932626..2cd5c8d4dc 100644
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/e
On 18.04.2022 11:07, Wei Chen wrote:
> VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
> results in two lines of error-checking code in phys_to_nid
> that is not actually working and causing two compilation
> errors:
> 1. error: "MAX_NUMNODES" undeclared (first use in this function).
>
flight 169723 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169723/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169694
test-amd64-amd64-qemuu-nested-amd 20
For the initialization of a ring page by the frontend two macros are
available in ring.h: SHARED_RING_INIT() and FRONT_RING_INIT().
All known users use always both of them in direct sequence.
Add another macro XEN_FRONT_RING_INIT() combining the two macros.
Signed-off-by: Juergen Gross
---
xen
On 18.04.2022 11:07, Wei Chen wrote:
> v1 ->v2:
> 1. Drop useless cast.
> 2. Use initializers of the variables.
Would have been nice if this was extended to ...
> diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
> index 680b7d9002..2b3a51afd0 100644
> --- a/xen/arch/x86/numa.c
> +++ b/xen/a
On 18.04.2022 11:07, Wei Chen wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -271,6 +271,35 @@ acpi_numa_processor_affinity_init(const struct
> acpi_srat_cpu_affinity *pa)
> pxm, pa->apic_id, node);
> }
>
> +/*
> + * Check to see if there are other node
On 14.04.2022 18:02, Roger Pau Monné wrote:
> On Thu, Apr 14, 2022 at 04:15:22PM +0200, Jan Beulich wrote:
>> On 14.04.2022 15:31, Roger Pau Monné wrote:
>>> On Thu, Apr 14, 2022 at 02:52:47PM +0200, Jan Beulich wrote:
On 14.04.2022 14:40, Roger Pau Monné wrote:
> On Tue, Apr 12, 2022 at 1
On 26.04.22 10:41, Borislav Petkov wrote:
On Tue, Apr 26, 2022 at 07:16:16AM +0200, Juergen Gross wrote:
Christoph suggested (rather firmly) this would be the way to go.
Yeah, I saw it but I don't think it is the right way to go.
What happens the next time a guest needs to query the platform
flight 169730 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 26.04.2022 11:08, Juergen Gross wrote:
> --- a/xen/include/public/io/ring.h
> +++ b/xen/include/public/io/ring.h
> @@ -184,6 +184,11 @@ typedef struct __name##_back_ring __name##_back_ring_t
>
> #define FRONT_RING_INIT(_r, _s, __size) FRONT_RING_ATTACH(_r, _s, 0, __size)
>
> +#define XEN_FR
Fresh from Linux 5.18-rc (and with adjustments to address issues noticed
while porting), except for the 1st patch.
1: switch to asm/intel-family.h naming
2: add SPR support
3: add 'preferred_cstates' module argument
4: add core C6 optimization for SPR
Jan
This brings us (back) closer to the original Linux source.
While touching mwait_idle_state_table_update() also drop a stray leading
blank.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -61,6 +61,7 @@
#include
#include
#include
+#incl
From: Artem Bityutskiy
Add Sapphire Rapids Xeon support.
Up until very recently, the C1 and C1E C-states were independent, but this
has changed in some new chips, including Sapphire Rapids Xeon (SPR). In these
chips the C1 and C1E states cannot be enabled at the same time. The "C1E
promotion" bi
From: Artem Bityutskiy
On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually
exclusive - only one of them can be enabled. By default, 'intel_idle' driver
enables C1 and disables C1E. However, some users prefer to use C1E instead of
C1, because it saves more energy.
This patc
From: Artem Bityutskiy
Add a Sapphire Rapids Xeon C6 optimization, similar to what we have for Sky Lake
Xeon: if package C6 is disabled, adjust C6 exit latency and target residency to
match core C6 values, instead of using the default package C6 values.
Signed-off-by: Artem Bityutskiy
Signed-of
flight 169731 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169731/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
... or so I hope. This series continues the attempt to deal with
the ovmf change putting the shared info page at a very high address
(which is now planned to get reverted there, but the general
problem doesn't go away by them doing so). There are further issues
with truncated value, which are being
Hi Andrew,
> On 26 Apr 2022, at 00:06, Andrew Cooper wrote:
>
> In a GNU compatbile makefile, $(LDFLAGS) are passed to $(CC), not $(LD).
You mean because CC is used for linking or even when compiling object files ?
If not, what is the expected way to pass linker flags ?
>
> In a default Cent
For one it is unnecessary to fill a perhaps large chunk of memory with
all ones. Add a new parameter to send_dirty_pages() for callers to
indicate so.
Then it is further unnecessary to allocate the dirty bitmap altogether
when all that's ever going to happen is a single all-dirty run.
Signed-off-
Like for the dirty bitmap, it is unnecessary to allocate the deferred-
pages bitmap when all that's ever going to happen is a single all-dirty
run.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
--- a/tools/libs/guest/xg_sr_save.c
+++ b/tools/libs/guest/xg_sr_save.c
@@ -130,7 +130,7 @@ s
struct xc_sr_record's length field has just 32 bits. Fill it early and
check that the calculated value hasn't overflowed. Additionally check
for counter overflow early - there's no point even trying to allocate
any memory in such an event.
While there also limit an induction variable's type to uns
The P2M, the use of PFNs, and hence the maximum valid PFN are purely
software constructs in PV. In principle a guest is free to use arbitrary
PFNs. However, at least page table normalization requires that PFN space
be, like MFN space, limited to the architectural 40 bits (52 address
bits). And of c
In send_memory_live() the precise value the dirty_count struct field
gets initialized to doesn't matter much (apart from the triggering of
the log message in send_dirty_pages(), see below), but it is important
that it not be zero on the first iteration (or else send_dirty_pages()
won't get called a
Just like for PV guests MMU_MACHPHYS_UPDATE implies marking of the
respective page as dirty, additions to a HVM guest's P2M should do so.
For HVM the opposite is also true: Pages being removed from the P2M are
no longer dirty at their prior GFN; there's no point in telling the tool
stack to try an
Let's try to avoid giving the impression that 32-bit tool stacks are as
capable as 64-bit ones.
Signed-off-by: Jan Beulich
---
v2: Wording adjustments as per review discussion.
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -137,6 +137,12 @@ ARM only has one guest type at the momen
## Toolstack
+Whil
In paging_log_dirty_op(), always update the count of pages field:
- if more pages were specified than the guest has ever accessed (HVM) or
marked part of the p2m (PV), there's no point for the caller to
inspect bits beyond the one for that last page,
- if the guest's p2m size has grown in the m
See the code comment. The higher the rate of vCPU-s migrating across
pCPU-s, the less useful this attempted optimization actually is. With
credit2 the migration rate looks to be unduly high even on mostly idle
systems, and hence on large systems lock contention here isn't very
difficult to observe
flight 169725 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169725/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169717
Tests which did not succee
Hi Jan,
On 2022/4/26 16:53, Jan Beulich wrote:
On 18.04.2022 11:07, Wei Chen wrote:
diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c
similarity index 71%
rename from xen/arch/x86/efi/stub.c
rename to xen/arch/x86/efi/stub-x86.c
index 9984932626..2cd5c8d4dc 100644
--- a/xen/arc
Hi Jan,
On 2022/4/26 17:11, Jan Beulich wrote:
On 18.04.2022 11:07, Wei Chen wrote:
v1 ->v2:
1. Drop useless cast.
2. Use initializers of the variables.
Would have been nice if this was extended to ...
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 680b7d9002..2b3a51afd0 10064
Hi Jan,
On 26/04/2022 11:33, Jan Beulich wrote:
See the code comment. The higher the rate of vCPU-s migrating across
pCPU-s, the less useful this attempted optimization actually is. With
credit2 the migration rate looks to be unduly high even on mostly idle
systems, and hence on large systems lo
On 4/26/22 02:35, Jan Beulich wrote:
On 25.04.2022 19:22, Daniel P. Smith wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -621,6 +621,9 @@ static void noreturn init_done(void)
void *va;
unsigned long start, end;
+if ( xsm_set_system_active() != 0 )
+pa
On Tue, Apr 26, 2022, 4:33 AM Julien Grall wrote:
> Hi,
>
> On 26/04/2022 09:17, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 11:24:37AM -0400, Tamas K Lengyel wrote:
> >> On Mon, Apr 25, 2022 at 10:12 AM Roger Pau Monné
> wrote:
> diff --git a/xen/common/vm_event.c b/xen/common/vm_ev
On 4/26/22 04:38, Jan Beulich wrote:
On 23.04.2022 01:07, Andrew Cooper wrote:
On 22/04/2022 20:43, Daniel P. Smith wrote:
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0bf63ffa84..e2ebbc7716 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -120,8 +121,8 @
On 26/04/2022 11:24, Jan Beulich wrote:
> In send_memory_live() the precise value the dirty_count struct field
> gets initialized to doesn't matter much
Yes it does.
And as you keep on refusing to actually fix the bugs pointed out during
review, this entire series is NACKED, seeing as you've also
flight 169732 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Jan,
On 2022/4/26 17:02, Jan Beulich wrote:
On 18.04.2022 11:07, Wei Chen wrote:
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" und
Hi Jan,
On 2022/4/26 17:20, Jan Beulich wrote:
On 18.04.2022 11:07, Wei Chen wrote:
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -271,6 +271,35 @@ acpi_numa_processor_affinity_init(const struct
acpi_srat_cpu_affinity *pa)
pxm, pa->apic_id, node);
}
+/*
+
On Tue, Apr 26, 2022 at 11:36:40AM +0200, Juergen Gross wrote:
> As the suggestion was to add another flag this wouldn't be a problem IMO.
We had a problem already with adding one flag would break the same flag
on the other guest type. That's why we added cc_vendor too. So it can be
tricky.
> pla
flight 169733 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 169727 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169727/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
Hi Jan,
> On 25 Apr 2022, at 11:47, Jan Beulich wrote:
>
> Just like for "install", make dealing with xen.efi on the EFI partition
> dependent upon mount point and vendor directory being known.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
>
> --- a/xen/Makef
Hi Jan,
> On 25 Apr 2022, at 11:46, Jan Beulich wrote:
>
> With debug info retained, xen.efi can be quite large. Unlike for xen.gz
> there's no intermediate step (mkelf32 there) involved which would strip
> debug info kind of as a side effect. While the installing of xen.efi on
> the EFI partiti
flight 169734 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169734/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
cppcheck can be used to check Xen code quality.
To create a report do "make cppcheck" on a built tree adding any options
you added during the process you used to build xen (like CROSS_COMPILE
or XEN_TARGET_ARCH). This will generate an xml report xen-cppcheck.xml.
To create a html report do "make
Hi Christoph,
> On 23 Apr 2022, at 6:14 pm, Christoph Hellwig wrote:
>
> swiotlb-xen uses very different ways to allocate coherent memory on x86
> vs arm. On the former it allocates memory from the page allocator, while
> on the later it reuses the dma-direct allocator the handles the
> complex
flight 169729 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 169630
test-armhf-a
flight 169735 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 169738 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 25.04.2022 15:28, David Vrabel wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -162,6 +162,13 @@
> static char __initdata opt_badpage[100] = "";
> string_param("badpage", opt_badpage);
>
> +/*
> + * Heap allocations may need TLB flushes which require IRQs to be
>
On 26.04.2022 14:26, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 25 Apr 2022, at 11:46, Jan Beulich wrote:
>>
>> With debug info retained, xen.efi can be quite large. Unlike for xen.gz
>> there's no intermediate step (mkelf32 there) involved which would strip
>> debug info kind of as a side effect.
Hi,
On 26/04/2022 15:01, Jan Beulich wrote:
On 25.04.2022 15:28, David Vrabel wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -162,6 +162,13 @@
static char __initdata opt_badpage[100] = "";
string_param("badpage", opt_badpage);
+/*
+ * Heap allocations may need TLB
On Fri, Apr 22, 2022 at 10:07:03AM -0400, Jason Andryuk wrote:
> PCI device assignment to an HVM with stubdom is potentially racy. First
> the PCI device is assigned to the stubdom via the PV PCI protocol. Then
> QEMU is sent a QMP command to attach the PCI device to QEMU running
> within the stu
On 26.04.2022 12:54, Andrew Cooper wrote:
> On 26/04/2022 11:24, Jan Beulich wrote:
>> In send_memory_live() the precise value the dirty_count struct field
>> gets initialized to doesn't matter much
>
> Yes it does.
>
> And as you keep on refusing to actually fix the bugs pointed out during
> rev
Reviewed-by: Sagi Grimberg
Hi all,
While looking at the I/O handling code, I noticed that hvmemul_do_io()
contains the following code:
333 rc = ioreq_send(s, &p, 0);
334 if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
335 vio->req.state = STATE_IOREQ_NONE;
Looking at his
On 26.04.2022 12:37, Wei Chen wrote:
> On 2022/4/26 16:53, Jan Beulich wrote:
>> On 18.04.2022 11:07, Wei Chen wrote:
>>> diff --git a/xen/arch/x86/efi/stub.c b/xen/arch/x86/efi/stub-x86.c
>>> similarity index 71%
>>> rename from xen/arch/x86/efi/stub.c
>>> rename to xen/arch/x86/efi/stub-x86.c
>>>
On 26/04/2022 15:14, Julien Grall wrote:
Hi,
On 26/04/2022 15:01, Jan Beulich wrote:
On 25.04.2022 15:28, David Vrabel wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -162,6 +162,13 @@
static char __initdata opt_badpage[100] = "";
string_param("badpage", opt_badpag
On 26/04/2022 15:33, David Vrabel wrote:
>
>
> On 26/04/2022 15:14, Julien Grall wrote:
>> Hi,
>>
>> On 26/04/2022 15:01, Jan Beulich wrote:
>>> On 25.04.2022 15:28, David Vrabel wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -162,6 +162,13 @@
static cha
On 26.04.2022 12:59, Wei Chen wrote:
> On 2022/4/26 17:02, Jan Beulich wrote:
>> On 18.04.2022 11:07, Wei Chen wrote:
>>> VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
>>> results in two lines of error-checking code in phys_to_nid
>>> that is not actually working and causing two compil
flight 169740 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169740/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Jan,
> On 26 Apr 2022, at 15:09, Jan Beulich wrote:
>
> On 26.04.2022 14:26, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 25 Apr 2022, at 11:46, Jan Beulich wrote:
>>>
>>> With debug info retained, xen.efi can be quite large. Unlike for xen.gz
>>> there's no intermediate step (mkelf32 ther
flight 169742 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 26.04.22 11:43, Jan Beulich wrote:
On 26.04.2022 11:08, Juergen Gross wrote:
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -184,6 +184,11 @@ typedef struct __name##_back_ring __name##_back_ring_t
#define FRONT_RING_INIT(_r, _s, __size) FRONT_RING_ATTACH(_r, _s,
Hello, Julien Grall.
Thanks you, I agreed! It made me think once more about what my patch
could improve.
patches I sent have been reviewed in various ways. It was a good
opportunity to analyze my patch from various perspectives. :)
I checked objdump in -O2 optimization(default) of Xen Makefile to
Reuse mask variables on order shift duplicated calculation.
Signed-off-by: Paran Lee
---
xen/arch/arm/p2m.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1d1059f7d2..cdb3b56aa1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/ar
When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
kernels had a bug where the physical address was copied directly from
ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
the same error by blindly copying across the max supported range.
Unsurprisingly when the
flight 169744 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169744/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 169737 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 169630
test-armhf-a
On Tue, Apr 26, 2022 at 10:10:37AM +0200, Steffen Einsle wrote:
> Hello,
>
> I can confirm that "msr_relaxed = 1" solves the problem with Server 2019
> Essentials crashing.
Can you post which CPU model are you using?
A dump of the first CPU entry in /proc/cpuinfo will do.
Thanks, Roger.
While reading C xenstored code, I noticed that it may send special events like
@releaseDomain to (privileged) clients that only watch the root node (/).
That's probably not the intended behaviour.
For example, when firing @releaseDomain, fire_watches() is called with exact ==
false:
https://gi
flight 169746 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169746/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hello,
Edvin has found a machine with some very weird properties. It is an HP
ProLiant BL460c Gen8 with:
\-[:00]-+-00.0 Intel Corporation Xeon E5/Core i7 DMI2
+-01.0-[11]--
+-01.1-[02]--
+-02.0-[04]--+-00.0 Emulex Corporation OneConnect 10Gb NIC
(be3
flight 169750 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Tue, Apr 26, 2022 at 4:50 AM Roger Pau Monné wrote:
>
> On Mon, Apr 25, 2022 at 11:40:11AM -0400, Tamas K Lengyel wrote:
> > On Mon, Apr 25, 2022 at 10:41 AM Roger Pau Monné
> > wrote:
> > >
> > > On Wed, Apr 13, 2022 at 09:41:52AM -0400, Tamas K Lengyel wrote:
> > > > Add monitor event that
On Wed, Apr 20, 2022 at 2:50 AM Jan Beulich wrote:
>
> On 20.04.2022 08:39, Tian, Kevin wrote:
> >> From: Tamas K Lengyel
> >> Sent: Tuesday, April 19, 2022 2:43 AM
> >>
> >> On Fri, Mar 25, 2022 at 9:34 AM Tamas K Lengyel
> >> wrote:
> >>>
> >>> During VM forking and resetting a failed vmentry
Hi,
On 26/04/2022 16:37, Paran Lee wrote:
Thanks you, I agreed! It made me think once more about what my patch
could improve.
patches I sent have been reviewed in various ways. It was a good
opportunity to analyze my patch from various perspectives. :)
I checked objdump in -O2 optimization(defa
Hi,
On 26/04/2022 16:49, Paran Lee wrote:
Reuse mask variables on order shift duplicated calculation.
Signed-off-by: Paran Lee
---
xen/arch/arm/p2m.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
It is common to add a changelog after "---". This helps the reviewer to
know
Thansk!
> It is common to add a changelog after "---". This helps the reviewer to
> know what changed in your patch.
I think this experience will be very helpful for the next more
meaningful patch.
>
> "1UL << order" refers to the number of pages and not a mask. So I don't
> think re-using the l
flight 169748 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169748/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
From: Julien Grall
Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap
alloc/free" extended the checks in the buddy allocator to catch
any use of the helpers from context with interrupts disabled.
Unfortunately, the rule is not followed in the alternative code and
this will result t
On 26/04/2022 15:14, Julien Grall wrote:
On 26/04/2022 15:01, Jan Beulich wrote:
On 25.04.2022 15:28, David Vrabel wrote:
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -162,6 +162,13 @@
static char __initdata opt_badpage[100] = "";
string_param("badpage", opt_badpage);
+/*
Add Rahul as ARM SMMU maintainer. Create a new explicit entry for "ARM
SMMU" also with Julien which is the original contributor of the code and
continues to maintain it.
Signed-off-by: Stefano Stabellini
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a47fafe85..ba0d1c0c1b 100644
--- a/MAINTAINER
flight 169754 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169754/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 169757 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169757/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Sat, 23 Apr 2022, Christoph Hellwig wrote:
> swiotlb-xen uses very different ways to allocate coherent memory on x86
> vs arm. On the former it allocates memory from the page allocator, while
> on the later it reuses the dma-direct allocator the handles the
> complexities of non-coherent DMA on
flight 169758 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/169758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Tue, 26 Apr 2022, Julien Grall wrote:
> From: Julien Grall
>
> Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap
> alloc/free" extended the checks in the buddy allocator to catch
> any use of the helpers from context with interrupts disabled.
>
> Unfortunately, the rule is not
1 - 100 of 123 matches
Mail list logo
