On 5/20/2022 2:05 AM, Jan Beulich wrote:
On 20.05.2022 06:43, Chuck Zmudzinski wrote:
On 5/4/22 5:14 AM, Juergen Gross wrote:
On 04.05.22 10:31, Jan Beulich wrote:
On 03.05.2022 15:22, Juergen Gross wrote:
Some drivers are using pat_enabled() in order to test availability of
special caching m
flight 170593 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170593/
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 5/20/2022 2:59 AM, Chuck Zmudzinski wrote:
On 5/20/2022 2:05 AM, Jan Beulich wrote:
On 20.05.2022 06:43, Chuck Zmudzinski wrote:
On 5/4/22 5:14 AM, Juergen Gross wrote:
On 04.05.22 10:31, Jan Beulich wrote:
On 03.05.2022 15:22, Juergen Gross wrote:
... these uses there are several more. Y
Intel LPSS has INTERRUPT_LINE set to 0xff by default, that is declared
by the PCI Local Bus Specification Revision 3.0 (from 2004) as
"unknown"/"no connection". Fallback to poll mode in this case.
The 0xff handling is x86-specific, the surrounding code is guarded with
CONFIG_X86 anyway.
Signed-off
This is purely based on the spec:
- Intel 500 Series PCH: 635218-006
- Intel 600 Series PCH: 691222-001, 648364-003
This is tested only on TGL-LP added initially, but according to the
spec, they should behave the same.
Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Andrew Cooper
---
Change
flight 170594 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170594/
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,
> On 19 May 2022, at 03:36, Wei Chen wrote:
>
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年5月18日 21:05
>> To: Wei Chen
>> Cc: nd ; Stefano Stabellini ; Julien
>> Grall ; Bertrand Marquis ;
>> Volodymyr Babchuk ; Andrew Cooper
>> ; Roger Pau Monné ; Wei
>> L
On 20.05.2022 10:30, Chuck Zmudzinski wrote:
> On 5/20/2022 2:59 AM, Chuck Zmudzinski wrote:
>> On 5/20/2022 2:05 AM, Jan Beulich wrote:
>>> On 20.05.2022 06:43, Chuck Zmudzinski wrote:
On 5/4/22 5:14 AM, Juergen Gross wrote:
> On 04.05.22 10:31, Jan Beulich wrote:
>> On 03.05.2022 15:
On 20.05.2022 10:53, Marek Marczykowski-Górecki wrote:
> This is purely based on the spec:
> - Intel 500 Series PCH: 635218-006
> - Intel 600 Series PCH: 691222-001, 648364-003
>
> This is tested only on TGL-LP added initially, but according to the
> spec, they should behave the same.
>
> Signed-
Hi Wei,
On 19/05/2022 03:36, Wei Chen wrote:
-Original Message-
From: Jan Beulich
Sent: 2022年5月18日 21:05
To: Wei Chen
Cc: nd ; Stefano Stabellini ; Julien
Grall ; Bertrand Marquis ;
Volodymyr Babchuk ; Andrew Cooper
; Roger Pau Monné ; Wei
Liu ; Jiamei Xie ; xen-
de...@lists.xenproject
On 20.05.2022 10:53, Marek Marczykowski-Górecki wrote:
> Intel LPSS has INTERRUPT_LINE set to 0xff by default, that is declared
> by the PCI Local Bus Specification Revision 3.0 (from 2004) as
> "unknown"/"no connection". Fallback to poll mode in this case.
> The 0xff handling is x86-specific, the
flight 170595 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170595/
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 170589 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170589/
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 Bertrand,
Since this patch has been committed, I get the following message for on
every build (make -C xen):
which: no cppcheck in ([...])
/bin/sh: cppcheck: command not found
I wasn't expecting the build system to check every time. I think...
On 26/04/2022 13:38, Bertrand Marquis wrote:
Hi Julien,
> On 20 May 2022, at 10:56, Julien Grall wrote:
>
> Hi Bertrand,
>
> Since this patch has been committed, I get the following message for on every
> build (make -C xen):
>
> which: no cppcheck in ([...])
> /bin/sh: cppcheck: command not found
>
> I wasn't expecting the build syste
On Thu, May 19, 2022 at 04:45:20PM +0200, Roger Pau Monné wrote:
> On Thu, May 19, 2022 at 12:10:24AM +, Andrew Cooper wrote:
> > On 17/05/2022 14:21, Roger Pau Monne wrote:
> > > @@ -1333,6 +1338,19 @@ static int construct_vmcs(struct vcpu *v)
> > > rc = vmx_add_msr(v, MSR_FLUSH_CMD,
flight 170586 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170586/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-saverestore.2 fail in 170563
pass in 170586
test-amd64-i386-
On Wed, May 18, 2022 at 12:06:29PM +0200, Jan Beulich wrote:
> On 06.05.2022 15:25, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:41:23AM +0200, Jan Beulich wrote:
> >> --- /dev/null
> >> +++ b/xen/arch/x86/include/asm/pt-contig-markers.h
> >> @@ -0,0 +1,105 @@
> >> +#ifndef __ASM_X86_PT_CO
flight 170597 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170597/
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 Fri, May 20, 2022 at 11:42:37AM +0200, Jan Beulich wrote:
> On 20.05.2022 10:53, Marek Marczykowski-Górecki wrote:
> > This is purely based on the spec:
> > - Intel 500 Series PCH: 635218-006
> > - Intel 600 Series PCH: 691222-001, 648364-003
> >
> > This is tested only on TGL-LP added initiall
On Fri, May 20, 2022 at 11:47:02AM +0200, Jan Beulich wrote:
> On 20.05.2022 10:53, Marek Marczykowski-Górecki wrote:
> > Intel LPSS has INTERRUPT_LINE set to 0xff by default, that is declared
> > by the PCI Local Bus Specification Revision 3.0 (from 2004) as
> > "unknown"/"no connection". Fallback
On Wed, May 18, 2022 at 12:40:59PM +0200, Jan Beulich wrote:
> On 10.05.2022 17:31, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:43:16AM +0200, Jan Beulich wrote:
> >> @@ -94,11 +95,15 @@ static union amd_iommu_pte set_iommu_pte
> >> old.iw != iw || old.ir != ir )
> >> {
> >
On Tue, Apr 19, 2022 at 06:56:03PM -0700, Elliott Mitchell wrote:
> Hopefully simplify future changes by sorting options lists for
> `xl create`. While at it, declare the options list constant.
>
> Signed-off-by: Elliott Mitchell
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Wed, May 18, 2022 at 12:44:06PM +0200, Jan Beulich wrote:
> On 11.05.2022 13:08, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:43:45AM +0200, Jan Beulich wrote:
> >> When a page table ends up with all contiguous entries (including all
> >> identical attributes), it can be replaced by a s
On Wed, May 18, 2022 at 01:39:02PM +0200, Jan Beulich wrote:
> On 11.05.2022 15:48, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:44:11AM +0200, Jan Beulich wrote:
> >> Signed-off-by: Jan Beulich
> >> Reviewed-by: Kevin tian
> >
> > Reviewed-by: Roger Pau Monné
>
> Thanks.
>
> > Would
On Thu, May 19, 2022 at 02:12:04PM +0200, Jan Beulich wrote:
> On 06.05.2022 13:16, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:40:55AM +0200, Jan Beulich wrote:
> >> ---
> >> An alternative to the ASSERT()s added to set_iommu_ptes_present() would
> >> be to make the function less general
If cppcheck is not present, the following warning appears during build:
which: no cppcheck in ([...])
/bin/sh: cppcheck: command not found
Fix this by hiding the error output from which and only try to execute
cppcheck --version if we have a cppcheck.
Reported-by: Julien Grall
Signed-off-by: Ber
On 20.05.2022 12:22, Roger Pau Monné wrote:
> On Wed, May 18, 2022 at 12:06:29PM +0200, Jan Beulich wrote:
>> On 06.05.2022 15:25, Roger Pau Monné wrote:
>>> On Mon, Apr 25, 2022 at 10:41:23AM +0200, Jan Beulich wrote:
--- /dev/null
+++ b/xen/arch/x86/include/asm/pt-contig-markers.h
On 20.05.2022 12:49, Bertrand Marquis wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -694,12 +694,13 @@ $(objtree)/%.c.cppcheck: $(srctree)/%.c
> $(objtree)/include/generated/autoconf.h
> $(call if_changed,cppcheck_xml)
>
> cppcheck-version:
> -ifeq ($(shell which $(CPPCHECK)),)
>
On 20.05.2022 12:47, Roger Pau Monné wrote:
> On Thu, May 19, 2022 at 02:12:04PM +0200, Jan Beulich wrote:
>> On 06.05.2022 13:16, Roger Pau Monné wrote:
>>> On Mon, Apr 25, 2022 at 10:40:55AM +0200, Jan Beulich wrote:
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passth
On Wed, May 18, 2022 at 12:26:03PM +0200, Jan Beulich wrote:
> On 10.05.2022 16:30, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:42:50AM +0200, Jan Beulich wrote:
> >> @@ -837,9 +843,31 @@ static int dma_pte_clear_one(struct doma
> >>
> >> old = *pte;
> >> dma_clear_pte(*pte);
On 20.05.2022 13:11, Jan Beulich wrote:
> On 20.05.2022 12:47, Roger Pau Monné wrote:
>> On Thu, May 19, 2022 at 02:12:04PM +0200, Jan Beulich wrote:
>>> On 06.05.2022 13:16, Roger Pau Monné wrote:
On Mon, Apr 25, 2022 at 10:40:55AM +0200, Jan Beulich wrote:
> --- a/xen/drivers/passthrough
On 19/05/2022 20:45, Baoquan He wrote:
> [...]
>> I really appreciate the summary skill you have, to convert complex
>> problems in very clear and concise ideas. Thanks for that, very useful!
>> I agree with what was summarized above.
>
> I want to say the similar words to Petr's reviewing comment
On Fri, May 20, 2022 at 12:59:55PM +0200, Jan Beulich wrote:
> On 20.05.2022 12:22, Roger Pau Monné wrote:
> > On Wed, May 18, 2022 at 12:06:29PM +0200, Jan Beulich wrote:
> >> On 06.05.2022 15:25, Roger Pau Monné wrote:
> >>> On Mon, Apr 25, 2022 at 10:41:23AM +0200, Jan Beulich wrote:
> ---
flight 170598 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170598/
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 170600 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170600/
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 Bertrand,
On 20/05/2022 11:49, Bertrand Marquis wrote:
If cppcheck is not present, the following warning appears during build:
which: no cppcheck in ([...])
/bin/sh: cppcheck: command not found
Fix this by hiding the error output from which and only try to execute
cppcheck --version if we ha
From: Julien Grall
Hi all,
This series was originally sent as "xen/arm: mm: Add limited support
for superpages" [1] and finally has grown enough to remove most of
the open-coding mappings in the boot code.
This will help to:
1) Get better compliance with the Arm memory model
2) Pave the
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() call by map_pages_to_xen() call.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v4:
- Add Stefano's reviewed-by
Changes i
From: Julien Grall
At the moment, xen_pt_update_entry() only supports mapping at level 3
(i.e 4KB mapping). While this is fine for most of the runtime helper,
the boot code will require to use superpage mapping.
We don't want to allow superpage mapping by default as some of the
callers may expec
From: Julien Grall
In follow-up patches, we will use xen_pt_update() (or its callers)
to handle large mappings (e.g. frametable, xenheap). They are also
not going to be modified once created.
The page-table entries have an hint to indicate that whether an
entry is contiguous to another 16 entrie
From: Julien Grall
Currently, the function xen_pt_update() will flush the TLBs even when
the mappings are inserted. This is a bit wasteful because we don't
allow mapping replacement. Even if we were, the flush would need to
happen earlier because mapping replacement should use Break-Before-Make
w
From: Julien Grall
Now that xen_pt_update_entry() is able to deal with different mapping
size, we can replace the open-coding of the page-tables update by a call
to modify_xen_mappings().
As the function is not meant to fail, a BUG_ON() is added to check the
return.
Note that we don't use destr
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() calls by map_pages_to_xen() calls.
The mapping can also be marked read-only as Xen should not modify
the host Device Tree during boot.
Signed-off-by: Julien Grall
Sign
From: Julien Grall
To use properly the fixmap definitions, their user would need
also new to include . This is not very great when
the user itself is not meant to directly use ACPI definitions.
Including in is not option because
the latter header is included by everyone. So move out the fixmap
From: Julien Grall
At the moment, page-table can only be allocated from domheap. This means
it is not possible to create mapping in the page-tables via
map_pages_to_xen() if page-table needs to be allocated.
In order to avoid open-coding page-tables update in early boot, we need
to be able to al
From: Julien Grall
xen_{un,}map_table() already uses the helper to map/unmap pages
on-demand (note this is currently a NOP on arm64). So switching to
domheap don't have any disavantage.
But this as the benefit:
- to keep the page tables unmapped if an arch decided to do so
- reduce xenhe
Hi Jan,
> On 20 May 2022, at 12:06, Jan Beulich wrote:
>
> On 20.05.2022 12:49, Bertrand Marquis wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -694,12 +694,13 @@ $(objtree)/%.c.cppcheck: $(srctree)/%.c
>> $(objtree)/include/generated/autoconf.h
>> $(call if_changed,cppcheck_xml)
From: Julien Grall
Currently, memory is added to the boot allocator after the xenheap
mappings are done. This will break if the first mapping is more than
512GB of RAM.
In addition to that, a follow-up patch will rework setup_xenheap_mappings()
to use smaller mappings (e.g. 2MB, 4KB). So it will
From: Julien Grall
The numbers of includes in mm.c has been growing quite a lot. However
some of them (e.g. xen/device_tree.h, xen/softirq.h) doesn't look
to be directly used by the file or other will be included by
larger headers (e.g asm/flushtlb.h will be included by xen/mm.h).
So trim down t
From: Wei Liu
The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We
pre-populate all the relevant page tables before the system is fully
set up.
We will need it on Arm in order to rework the arm64 version of
xenheap_setup_mappings() as we may need to use pages allocated from
the boot
From: Julien Grall
Now that map_pages_to_xen() has been extended to support 2MB mappings,
we can replace the create_mappings() call by map_pages_to_xen() call.
This has the advantage to remove the differences between 32-bit and
64-bit code.
Lastly remove create_mappings() as there is no more ca
From: Julien Grall
The current implementation of setup_xenheap_mappings() is using 1GB
mappings. This can lead to unexpected result because the mapping
may alias a non-cachable region (such as device or reserved regions).
For more details see B2.8 in ARM DDI 0487H.a.
map_pages_to_xen() was recen
From: Julien Grall
In a follow-up patch, we will want to populate the boot allocator
separately for arm64. The code will end up to be very similar to the one
on arm32. So move out the code in a new helper populate_boot_allocator().
For now the code is still protected by CONFIG_ARM_32 to avoid an
If cppcheck is not present, the following warning appears during build:
which: no cppcheck in ([...])
/bin/sh: cppcheck: command not found
Fix the problem by using shell code inside the cppcheck-version rule to
also prevent unneeded call of which when something else than cppcheck is
built.
Report
From: Julien Grall
During early boot, it is not possible to use xen_{,un}map_table()
if the page tables are not residing the Xen binary.
This is a blocker to switch some of the helpers to use xen_pt_update()
as we may need to allocate extra page tables and access them before
the domheap has been
On Fri, May 20, 2022 at 01:13:28PM +0200, Jan Beulich wrote:
> On 20.05.2022 13:11, Jan Beulich wrote:
> > On 20.05.2022 12:47, Roger Pau Monné wrote:
> >> On Thu, May 19, 2022 at 02:12:04PM +0200, Jan Beulich wrote:
> >>> On 06.05.2022 13:16, Roger Pau Monné wrote:
> On Mon, Apr 25, 2022 at 1
flight 170601 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170601/
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 20.05.2022 14:22, Roger Pau Monné wrote:
> On Fri, May 20, 2022 at 01:13:28PM +0200, Jan Beulich wrote:
>> On 20.05.2022 13:11, Jan Beulich wrote:
>>> On 20.05.2022 12:47, Roger Pau Monné wrote:
On Thu, May 19, 2022 at 02:12:04PM +0200, Jan Beulich wrote:
> On 06.05.2022 13:16, Roger Pa
On Thu, Apr 21, 2022 at 03:21:08PM +0200, Roger Pau Monne wrote:
> Hello,
>
> Following series attempts to solve the issue with IO-APIC edge triggered
> interrupts seeing an inconsistent RTE or IRTE when injected while being
> migrated.
>
> It's currently RFC because some patches have post commit
On Fri, May 20, 2022 at 08:24:48AM +0200, Jan Beulich wrote:
> On 20.05.2022 01:22, Demi Marie Obenour wrote:
> > It is well known that mapping and unmapping grants is expensive, which
> > is why blkback has persistent grants. Could this cost be mitigated by
> > batching, and if it was, would it a
On 20.05.2022 14:37, Demi Marie Obenour wrote:
> On Fri, May 20, 2022 at 08:24:48AM +0200, Jan Beulich wrote:
>> On 20.05.2022 01:22, Demi Marie Obenour wrote:
>>> It is well known that mapping and unmapping grants is expensive, which
>>> is why blkback has persistent grants. Could this cost be mi
On 20.05.2022 14:36, Roger Pau Monné wrote:
> On Thu, Apr 21, 2022 at 03:21:08PM +0200, Roger Pau Monne wrote:
>> Hello,
>>
>> Following series attempts to solve the issue with IO-APIC edge triggered
>> interrupts seeing an inconsistent RTE or IRTE when injected while being
>> migrated.
>>
>> It's
On 20.05.2022 14:14, Bertrand Marquis wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -694,12 +694,14 @@ $(objtree)/%.c.cppcheck: $(srctree)/%.c
> $(objtree)/include/generated/autoconf.h
> $(call if_changed,cppcheck_xml)
>
> cppcheck-version:
> -ifeq ($(shell which $(CPPCHECK)),)
>
Hi,
> On 20 May 2022, at 13:51, Jan Beulich wrote:
>
> On 20.05.2022 14:14, Bertrand Marquis wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -694,12 +694,14 @@ $(objtree)/%.c.cppcheck: $(srctree)/%.c
>> $(objtree)/include/generated/autoconf.h
>> $(call if_changed,cppcheck_xml)
>>
flight 170602 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170602/
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 5/20/2022 5:41 AM, Jan Beulich wrote:
On 20.05.2022 10:30, Chuck Zmudzinski wrote:
On 5/20/2022 2:59 AM, Chuck Zmudzinski wrote:
On 5/20/2022 2:05 AM, Jan Beulich wrote:
On 20.05.2022 06:43, Chuck Zmudzinski wrote:
On 5/4/22 5:14 AM, Juergen Gross wrote:
On 04.05.22 10:31, Jan Beulich wro
Allow exposing the PDCM bit in CPUID for HVM guests if present on the
platform, which in turn allows exposing PERF_CAPABILITIES. Limit the
information exposed in PERF_CAPABILITIES to the LBR format only.
This is helpful as hardware without model-specific LBRs set format to
0x3f in order to notify
Hello,
Intel Sapphire Rapids CPUs doesn't have model-specific MSRs, and hence
only architectural LBRs are available.
Firstly implement some changes so Xen knows how to enable arch LBRs so
that the ler option can also work in such scenario (first two patches).
The lack of model-specific LBRs also
Properly indent the handling of LBR enable in MSR_IA32_DEBUGCTLMSR
vmx_msr_write_intercept().
No functional change.
Signed-off-by: Roger Pau Monné
---
Feel free to squash onto the previous patch, did separately to aid the
readability of the previous change.
---
xen/arch/x86/hvm/vmx/vmx.c | 38 +
It's more consistent with the rest of the usages of cpu_has_xen_lbr.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/x86_64/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index
CPUs having no model-specific LBRs don't implement DEBUGCTLMSR.LBR
and LBRs can only be enabled if the processor supports architectural
LBRs.
Split the logic to enable LBRs into a separate function and expand the
logic to also implement support for arch LBRs if model-specific LBRs
are not supporte
Sapphire Rapids have no model-specific LBRs, and instead only expose
architectural LBRs. As documented in the Architectural Last Branch
Records specification, processors not supporting model-specific LBRs
MSR_IA32_DEBUGCTLMSR.LBR has no meaning, and can be written to 0 or 1,
but reads will always
On Fri, May 20, 2022 at 02:46:39PM +0200, Jan Beulich wrote:
> On 20.05.2022 14:36, Roger Pau Monné wrote:
> > On Thu, Apr 21, 2022 at 03:21:08PM +0200, Roger Pau Monne wrote:
> >> Hello,
> >>
> >> Following series attempts to solve the issue with IO-APIC edge triggered
> >> interrupts seeing an in
On Fri, Apr 29, 2022 at 03:45:25PM -0700, Elliott Mitchell wrote:
> Rather than having shadow variables for every element of dom_info, it is
> better to properly initialize dom_info at the start. This also removes
> the misleading memset() in the middle of main_create().
>
> Remove the dryrun ele
On 20.05.2022 15:23, Bertrand Marquis wrote:
>> On 20 May 2022, at 13:51, Jan Beulich wrote:
>> On 20.05.2022 14:14, Bertrand Marquis wrote:
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -694,12 +694,14 @@ $(objtree)/%.c.cppcheck: $(srctree)/%.c
>>> $(objtree)/include/generated/autoconf.h
flight 170603 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170603/
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
> -Original Message-
> From: Tian, Kevin
> Sent: Thursday, May 19, 2022 8:35 PM
> To: Tamas K Lengyel ; xen-
> de...@lists.xenproject.org
> Cc: Lengyel, Tamas ; Wei Liu ;
> Anthony PERARD ; Gross, Jurgen
> ; Cooper, Andrew ;
> George Dunlap ; Beulich, Jan
> ; Julien Grall ; Stefano Stabe
On 20.05.2022 15:33, Chuck Zmudzinski wrote:
> On 5/20/2022 5:41 AM, Jan Beulich wrote:
>> On 20.05.2022 10:30, Chuck Zmudzinski wrote:
>>> On 5/20/2022 2:59 AM, Chuck Zmudzinski wrote:
On 5/20/2022 2:05 AM, Jan Beulich wrote:
> On 20.05.2022 06:43, Chuck Zmudzinski wrote:
>> On 5/4/22
On 20/05/2022 14:37, Roger Pau Monne wrote:
> Allow exposing the PDCM bit in CPUID for HVM guests if present on the
> platform, which in turn allows exposing PERF_CAPABILITIES. Limit the
> information exposed in PERF_CAPABILITIES to the LBR format only.
>
> This is helpful as hardware without mode
On Tue, Apr 19, 2022 at 06:23:41PM -0700, Elliott Mitchell wrote:
> JSON is currently used when saving domains to mass storage. Being able
> to use JSON as the normal input to `xl create` has potential to be
> valuable. Add the functionality.
>
> Move the memset() earlier so to allow use of the
Hi Jan,
> On 20 May 2022, at 14:56, Jan Beulich wrote:
>
> On 20.05.2022 15:23, Bertrand Marquis wrote:
>>> On 20 May 2022, at 13:51, Jan Beulich wrote:
>>> On 20.05.2022 14:14, Bertrand Marquis wrote:
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -694,12 +694,14 @@ $(objtree)/%.c.cpp
On 20.05.2022 16:10, Andrew Cooper wrote:
> On 20/05/2022 14:37, Roger Pau Monne wrote:
>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>> @@ -135,7 +135,7 @@ XEN_CPUFEATURE(SSSE3, 1*32+ 9) /*A Supplemental
>> Streaming SIMD Extens
On Fri, May 20, 2022 at 02:36:02PM +0200, Jan Beulich wrote:
> On 20.05.2022 14:22, Roger Pau Monné wrote:
> > On Fri, May 20, 2022 at 01:13:28PM +0200, Jan Beulich wrote:
> >> On 20.05.2022 13:11, Jan Beulich wrote:
> >>> On 20.05.2022 12:47, Roger Pau Monné wrote:
> On Thu, May 19, 2022 at 0
flight 170604 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170604/
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 Fri, May 20, 2022 at 04:28:14PM +0200, Roger Pau Monné wrote:
> On Fri, May 20, 2022 at 02:36:02PM +0200, Jan Beulich wrote:
> > On 20.05.2022 14:22, Roger Pau Monné wrote:
> > > On Fri, May 20, 2022 at 01:13:28PM +0200, Jan Beulich wrote:
> > >> On 20.05.2022 13:11, Jan Beulich wrote:
> > >>> O
flight 170599 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170599/
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
On 5/20/2022 10:06 AM, Jan Beulich wrote:
On 20.05.2022 15:33, Chuck Zmudzinski wrote:
On 5/20/2022 5:41 AM, Jan Beulich wrote:
On 20.05.2022 10:30, Chuck Zmudzinski wrote:
On 5/20/2022 2:59 AM, Chuck Zmudzinski wrote:
On 5/20/2022 2:05 AM, Jan Beulich wrote:
On 20.05.2022 06:43, Chuck Zmudz
On Fri, May 20, 2022 at 02:10:31PM +, Andrew Cooper wrote:
> On 20/05/2022 14:37, Roger Pau Monne wrote:
> > Allow exposing the PDCM bit in CPUID for HVM guests if present on the
> > platform, which in turn allows exposing PERF_CAPABILITIES. Limit the
> > information exposed in PERF_CAPABILITI
On 20/05/2022 15:19, Jan Beulich wrote:
> On 20.05.2022 16:10, Andrew Cooper wrote:
>> On 20/05/2022 14:37, Roger Pau Monne wrote:
>>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>>> @@ -135,7 +135,7 @@ XEN_CPUFEATURE(SSSE3, 1*32+
On Thu, May 19, 2022 at 08:16:16PM +0300, Oleksandr wrote:
> On 18.05.22 14:05, Anthony PERARD wrote:
> > On Tue, May 03, 2022 at 08:26:03PM +0300, Oleksandr Tyshchenko wrote:
> > > +for (i = 0; i < d_config->num_disks; i++) {
> > > +libxl_device_disk *disk = &d_config->disks[i];
> > >
flight 170605 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170605/
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 5/20/2022 10:06 AM, Jan Beulich wrote:
On 20.05.2022 15:33, Chuck Zmudzinski wrote:
On 5/20/2022 5:41 AM, Jan Beulich wrote:
On 20.05.2022 10:30, Chuck Zmudzinski wrote:
On 5/20/2022 2:59 AM, Chuck Zmudzinski wrote:
On 5/20/2022 2:05 AM, Jan Beulich wrote:
On 20.05.2022 06:43, Chuck Zmudz
flight 170592 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170592/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170581
test-armhf-armhf-libvirt 16 saver
flight 170607 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170607/
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
Anthony PERARD writes ("[OSSTEST PATCH v2] ts-xen-build-prep: Install newer
NASM version, to build OVMF"):
> Recent versions of OVMF now need a version of NASM that is newer
> than the one available on Debian oldstable/buster. They want to use
> NASM 2.15.05 [1], which is available in Debian stabl
I think this summary of the regression is appropriate for a top-post.
Details follow below.
commit bdd8b6c98239: introduced what I call a real regression which
persists in 5.17.x
Jan's proposed patch:
https://lore.kernel.org/lkml/9385fa60-fa5d-f559-a137-6608408f8...@suse.com/
Jan's patch w
On 5/20/2022 1:13 PM, Chuck Zmudzinski wrote:
I think this summary of the regression is appropriate for a top-post.
Details follow below.
commit bdd8b6c98239: introduced what I call a real regression which
persists in 5.17.x
Jan's proposed patch:
https://lore.kernel.org/lkml/9385fa60-fa5d-f
On 18.05.22 13:52, Anthony PERARD wrote:
Hello Anthony
On Tue, May 03, 2022 at 08:26:02PM +0300, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-mmio
based virtio-disk backend (emulator) which is intended to run ou
flight 170608 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170608/
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
1 - 100 of 112 matches
Mail list logo
