On 19/11/2022 01:45, Henry Wang wrote:
> Hi Anthony and Andrew,
>
>> -Original Message-
>> From: Anthony PERARD
>> Subject: Re: [PATCH for-4.17] tools/libxl: Correct error message units in
>> libxl__domain_set_paging_mempool_size()
>>
>> On Fri, Nov 18, 2022 at 05:02:13PM +, Andrew Coo
On Mon, Nov 21, 2022 at 09:33:53AM +0100, Jan Beulich wrote:
> On 18.11.2022 15:26, Roger Pau Monné wrote:
> > On Fri, Nov 18, 2022 at 11:31:28AM +0100, Jan Beulich wrote:
> >> Linux'es relatively new use of HVMOP_set_evtchn_upcall_vector has
> >> exposed a problem with the marking of the respectiv
Hi Andrew,
> -Original Message-
> Subject: Re: [PATCH for-4.17] tools/libxl: Correct error message units in
> libxl__domain_set_paging_mempool_size()
>
> On Fri, Nov 18, 2022 at 05:02:13PM +, Andrew Cooper wrote:
> > diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_d
flight 174874 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174874/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-saverestore
fail REGR. vs. 174797
Hi Roger and Jan,
> -Original Message-
> Subject: Re: [PATCH v2] efifb: ignore frame buffer with invalid configuration
>
> On 18.11.2022 15:11, Roger Pau Monne wrote:
> > On one of my boxes when the HDMI cable is not plugged in the
> > FrameBufferBase of the EFI_GRAPHICS_OUTPUT_PROTOCOL_M
On 21.11.2022 11:53, Roger Pau Monné wrote:
> On Mon, Nov 21, 2022 at 09:33:53AM +0100, Jan Beulich wrote:
>> On 18.11.2022 15:26, Roger Pau Monné wrote:
>>> Maybe best to add an ASSERT in vlapic_set_irq() to be sure the lapic is
>>> enabled, as other callers already check this before trying to inj
On 18/11/2022 21:10, Jason Andryuk wrote:
> On Fri, Nov 18, 2022 at 12:22 PM Andrew Cooper
> wrote:
>> On 18/11/2022 14:39, Roger Pau Monne wrote:
>>> Nov 18 01:55:11.753936 (XEN) arch/x86/mm/hap/hap.c:304: d1 failed to
>>> allocate from HAP pool
>>> Nov 18 01:55:18.633799 (XEN) Failed to shatter
On 21.11.2022 09:33, Jan Beulich wrote:
> On 18.11.2022 15:26, Roger Pau Monné wrote:
>> Maybe best to add an ASSERT in vlapic_set_irq() to be sure the lapic is
>> enabled, as other callers already check this before trying to inject?
>
> Perhaps, yes (once we've fixed paths where the check is pres
In software-disabled state an LAPIC does not accept any interrupt
requests and hence no IRR bit would newly become set while in this
state. As a result it is also wrong for us to mark IO-APIC or MSI
originating vectors as having a pending request when the vLAPIC is in
this state. Such interrupts ar
In software-disabled state an LAPIC does not accept any interrupt
requests and hence no IRR bit would newly become set while in this
state. As a result it is also wrong for us to mark Viridian IPI or timer
vectors as having a pending request when the vLAPIC is in this state.
Such interrupts are sim
On 11/21/22 03:04, Jan Beulich wrote:
On 20.11.2022 12:08, Daniel P. Smith wrote:
On 11/18/22 16:10, Jason Andryuk wrote:
On Fri, Nov 18, 2022 at 12:22 PM Andrew Cooper
wrote:
For Flask, we need new access vectors because this is a common
hypercall, but I'm unsure how to interlink it with x8
On 21/11/2022 08:56, Jan Beulich wrote:
> On 18.11.2022 15:27, Andrew Cooper wrote:
>> On 18/11/2022 12:54, Jan Beulich wrote:
>>> On 18.11.2022 13:33, Andrew Cooper wrote:
On 18/11/2022 10:31, Jan Beulich wrote:
> Linux'es relatively new use of HVMOP_set_evtchn_upcall_vector has
> exp
On 21.11.2022 13:23, Andrew Cooper wrote:
> On 21/11/2022 08:56, Jan Beulich wrote:
>> On 18.11.2022 15:27, Andrew Cooper wrote:
>>> On 18/11/2022 12:54, Jan Beulich wrote:
On 18.11.2022 13:33, Andrew Cooper wrote:
> On 18/11/2022 10:31, Jan Beulich wrote:
>> Linux'es relatively new us
On 11.10.2022 11:28, Jan Beulich wrote:
> find_ring_mfn() already holds a page reference when trying to obtain a
> writable type reference. We shouldn't make assumptions on the general
> reference count limit being effectively "infinity". Obtain merely a type
> ref, re-using the general ref by only
On 21.11.2022 11:21, Roger Pau Monne wrote:
> @@ -47,6 +49,15 @@ static bool __init
> processor_physically_present(acpi_handle handle)
> return false;
> }
>
> + if (xen_initial_domain())
> + /*
> + * When running as a Xen dom0 the number of proces
On 21.11.2022 11:21, Roger Pau Monne wrote:
> --- a/drivers/acpi/processor_pdc.c
> +++ b/drivers/acpi/processor_pdc.c
> @@ -137,6 +137,14 @@ acpi_processor_eval_pdc(acpi_handle handle, struct
> acpi_object_list *pdc_in)
> buffer[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
>
>
On 21.11.2022 15:10, Jan Beulich wrote:
> On 21.11.2022 11:21, Roger Pau Monne wrote:
>> --- a/drivers/acpi/processor_pdc.c
>> +++ b/drivers/acpi/processor_pdc.c
>> @@ -137,6 +137,14 @@ acpi_processor_eval_pdc(acpi_handle handle, struct
>> acpi_object_list *pdc_in)
>> buffer[2] &= ~(A
On 21.11.2022 11:21, Roger Pau Monne wrote:
> Hello,
>
> This series aims to fix some shortcomings with the handling of ACPI
> Processors objects when running as a Xen dom0.
>
> First two patches fix the execution of the _PDC methods for all CPUs on
> the system and not just the ones available to
On Mon, Nov 21, 2022 at 03:02:30PM +0100, Jan Beulich wrote:
> On 21.11.2022 11:21, Roger Pau Monne wrote:
> > @@ -47,6 +49,15 @@ static bool __init
> > processor_physically_present(acpi_handle handle)
> > return false;
> > }
> >
> > + if (xen_initial_domain())
> > +
The error message accidentally printed the bytes value as if it were kB.
Furthermore, both b_info.shadow_memkb and shadow_mem are uint64_t, meaning
there is a risk of overflow if the user specified a stupidly large value in
the vm.cfg file. Check and reject such a condition.
Fixes: 7c3bbd940dd8
These were overlooked in the original patch, and noticed by OSSTest which does
run some Flask tests.
Fixes: 22b20bd98c02 ("xen: Introduce non-broken hypercalls for the paging
mempool size")
Suggested-by: Daniel Smith
Signed-off-by: Andrew Cooper
---
CC: Daniel De Graaf
CC: Daniel Smith
CC: Ja
Once more, with feeling...
Patch 1 has been posted previously, but has accumulated another bugfix.
Patch 2 has been discussed on list, but this is the first posting. I've
confirmed that it fixes the issue reported by OSSTest.
Andrew Cooper (2):
tools/libxl: Fixes to libxl__domain_set_paging_m
On 21/11/2022 12:13, Jan Beulich wrote:
> In software-disabled state an LAPIC does not accept any interrupt
> requests and hence no IRR bit would newly become set while in this
> state. As a result it is also wrong for us to mark IO-APIC or MSI
> originating vectors as having a pending request when
On Mon, Nov 21, 2022 at 02:37:30PM +, Andrew Cooper wrote:
> The error message accidentally printed the bytes value as if it were kB.
>
> Furthermore, both b_info.shadow_memkb and shadow_mem are uint64_t, meaning
> there is a risk of overflow if the user specified a stupidly large value in
> t
On 21/11/2022 12:13, Jan Beulich wrote:
> In software-disabled state an LAPIC does not accept any interrupt
> requests and hence no IRR bit would newly become set while in this
> state. As a result it is also wrong for us to mark Viridian IPI or timer
> vectors as having a pending request when the
Hi x86 devs,
I want to ask you some questions about this patch because in the previous
version me and Julien have discussed how cache colors should be passed in
domain creation. You should be able to read that discussion, anyway here is
a link to it
https://marc.info/?l=xen-devel&m=16615180200226
On 21.11.2022 15:29, Roger Pau Monné wrote:
> On Mon, Nov 21, 2022 at 03:02:30PM +0100, Jan Beulich wrote:
>> On 21.11.2022 11:21, Roger Pau Monne wrote:
>>> @@ -47,6 +49,15 @@ static bool __init
>>> processor_physically_present(acpi_handle handle)
>>> return false;
>>> }
>>>
>>>
On Mon, Nov 21, 2022 at 03:10:36PM +0100, Jan Beulich wrote:
> On 21.11.2022 11:21, Roger Pau Monne wrote:
> > --- a/drivers/acpi/processor_pdc.c
> > +++ b/drivers/acpi/processor_pdc.c
> > @@ -137,6 +137,14 @@ acpi_processor_eval_pdc(acpi_handle handle, struct
> > acpi_object_list *pdc_in)
> >
On Mon, Nov 21, 2022 at 03:51:58PM +0100, Jan Beulich wrote:
> On 21.11.2022 15:29, Roger Pau Monné wrote:
> > On Mon, Nov 21, 2022 at 03:02:30PM +0100, Jan Beulich wrote:
> >> On 21.11.2022 11:21, Roger Pau Monne wrote:
> >>> @@ -47,6 +49,15 @@ static bool __init
> >>> processor_physically_presen
On 21.11.2022 15:50, Carlo Nonato wrote:
> Hi x86 devs,
Any reason you didn't include Roger?
> I want to ask you some questions about this patch because in the previous
> version me and Julien have discussed how cache colors should be passed in
> domain creation. You should be able to read that d
Hi Andrew,
> -Original Message-
> Subject: Re: [PATCH 1/2] tools/libxl: Fixes to
> libxl__domain_set_paging_mempool_size()
>
> On Mon, Nov 21, 2022 at 02:37:30PM +, Andrew Cooper wrote:
> > The error message accidentally printed the bytes value as if it were kB.
> >
> > Furthermore, b
Hi Andrew,
> -Original Message-
> From: Andrew Cooper
> Sent: Monday, November 21, 2022 10:38 PM
> To: Xen-devel
> Cc: Andrew Cooper ; Daniel De Graaf
> ; Daniel Smith ;
> Jason Andryuk ; Henry Wang
>
> Subject: [PATCH 2/2] xen/flask: Wire up
> XEN_DOMCTL_{get,set}_paging_mempool_size
>
On Mon, Nov 21, 2022 at 9:37 AM Andrew Cooper wrote:
>
> These were overlooked in the original patch, and noticed by OSSTest which does
> run some Flask tests.
>
> Fixes: 22b20bd98c02 ("xen: Introduce non-broken hypercalls for the paging
> mempool size")
> Suggested-by: Daniel Smith
> Signed-off
On Sat, Nov 19, 2022 at 11:33 AM Marek Marczykowski-Górecki
wrote:
>
> On Sat, Nov 19, 2022 at 09:36:54AM -0500, Jason Andryuk wrote:
> > Hi, Marek,
> >
> > On Fri, Nov 18, 2022 at 4:46 PM Marek Marczykowski-Górecki
> > wrote:
> > >
> > > On Fri, Nov 18, 2022 at 03:46:47PM -0500, Jason Andryuk wr
On 21/11/2022 15:39, Jason Andryuk wrote:
> On Mon, Nov 21, 2022 at 9:37 AM Andrew Cooper
> wrote:
>> These were overlooked in the original patch, and noticed by OSSTest which
>> does
>> run some Flask tests.
>>
>> Fixes: 22b20bd98c02 ("xen: Introduce non-broken hypercalls for the paging
>> mem
On Mon, Nov 21, 2022 at 10:46 AM Andrew Cooper
wrote:
>
> On 21/11/2022 15:39, Jason Andryuk wrote:
> > On Mon, Nov 21, 2022 at 9:37 AM Andrew Cooper
> > wrote:
> >> These were overlooked in the original patch, and noticed by OSSTest which
> >> does
> >> run some Flask tests.
> >>
> >> Fixes: 2
On 11/21/22 09:37, Andrew Cooper wrote:
These were overlooked in the original patch, and noticed by OSSTest which does
run some Flask tests.
Fixes: 22b20bd98c02 ("xen: Introduce non-broken hypercalls for the paging mempool
size")
Suggested-by: Daniel Smith
Signed-off-by: Andrew Cooper
---
C
On Mon, Nov 21, 2022 at 10:41:34AM -0500, Jason Andryuk wrote:
> On Sat, Nov 19, 2022 at 11:33 AM Marek Marczykowski-Górecki
> wrote:
> >
> > On Sat, Nov 19, 2022 at 09:36:54AM -0500, Jason Andryuk wrote:
> > > Hi, Marek,
> > >
> > > On Fri, Nov 18, 2022 at 4:46 PM Marek Marczykowski-Górecki
> > >
On Mon, Nov 21, 2022 at 4:14 PM Jan Beulich wrote:
>
> On 21.11.2022 15:50, Carlo Nonato wrote:
> > Hi x86 devs,
>
> Any reason you didn't include Roger?
Nope. Sorry, forgot to add him.
> > I want to ask you some questions about this patch because in the previous
> > version me and Julien have d
flight 174883 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174883/
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
Hello,
on a system with these first two EFI memory map entries
(XEN) 0-9dfff type=4 attr=000f
(XEN) 9e000-9 type=2 attr=000f
i.e. except for 2 pages all space below 1M being BootServicesData, the
-mapbs option has the effect of ma
On Mon, Nov 21, 2022 at 03:20:53PM +0100, Jan Beulich wrote:
> On 21.11.2022 11:21, Roger Pau Monne wrote:
> > Hello,
> >
> > This series aims to fix some shortcomings with the handling of ACPI
> > Processors objects when running as a Xen dom0.
> >
> > First two patches fix the execution of the _
On 21.11.2022 17:23, Carlo Nonato wrote:
> On Mon, Nov 21, 2022 at 4:14 PM Jan Beulich wrote:
>> On 21.11.2022 15:50, Carlo Nonato wrote:
>>> I want to ask you some questions about this patch because in the previous
>>> version me and Julien have discussed how cache colors should be passed in
>>>
On Mon, Nov 21, 2022 at 05:27:16PM +0100, Jan Beulich wrote:
> Hello,
>
> on a system with these first two EFI memory map entries
>
> (XEN) 0-9dfff type=4 attr=000f
> (XEN) 9e000-9 type=2 attr=000f
>
> i.e. except for 2 pages all
flight 174878 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174878/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
On 21.11.2022 17:48, Roger Pau Monné wrote:
> On Mon, Nov 21, 2022 at 05:27:16PM +0100, Jan Beulich wrote:
>> Hello,
>>
>> on a system with these first two EFI memory map entries
>>
>> (XEN) 0-9dfff type=4 attr=000f
>> (XEN) 9e000-9 type=2 attr=
On 21/11/2022 12:13, Jan Beulich wrote:
In software-disabled state an LAPIC does not accept any interrupt
requests and hence no IRR bit would newly become set while in this
state. As a result it is also wrong for us to mark Viridian IPI or timer
vectors as having a pending request when the vLAPIC
flight 174889 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174889/
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
flight 174881 xen-unstable real [real]
flight 174892 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/174881/
http://logs.test-lab.xenproject.org/osstest/logs/174892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree
flight 174890 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174890/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken
test-arm64-arm64-examine 8 reboot
flight 174896 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174896/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64broken
test-amd64-i386-xl-qemut-debia
Hi,
> -Original Message-
> Subject: [xen-unstable test] 174896: regressions - trouble: broken/fail/pass
>
> flight 174896 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/174896/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> includin
flight 174899 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174899/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow222 guest-start.2 fail blocked in 174807
test-amd64-amd64-xl-qemuu-win7-amd6
When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
Linux SBSA PL011 driver will access PL011 DMACR register in some
functions. As chapter "B Generic UART" in "ARM Server Base System
Architecture"[1] documentation describes, SBSA UART doesn't support
DMA. In current code, when the
On 22.11.2022 05:40, Henry Wang wrote:
> Hi,
>
>> -Original Message-
>> Subject: [xen-unstable test] 174896: regressions - trouble: broken/fail/pass
>>
>> flight 174896 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/174896/
>>
>> Regressions :-(
>>
>> Tests w
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [xen-unstable test] 174896: regressions - trouble:
> broken/fail/pass
>
> On 22.11.2022 05:40, Henry Wang wrote:
> > Hi,
> >
> >> -Original Message-
> >> Subject: [xen-unstable test] 174896: regressions - trouble:
>
On 22.11.2022 08:30, Henry Wang wrote:
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Subject: Re: [xen-unstable test] 174896: regressions - trouble:
>> broken/fail/pass
>>
>> On 22.11.2022 05:40, Henry Wang wrote:
>>> Hi,
>>>
-Original Message-
Subject: [xen-
On 20.11.2022 12:08, Daniel P. Smith wrote:
> On 11/18/22 16:10, Jason Andryuk wrote:
>> On Fri, Nov 18, 2022 at 12:22 PM Andrew Cooper
>> wrote:
>>> For Flask, we need new access vectors because this is a common
>>> hypercall, but I'm unsure how to interlink it with x86's shadow
>>> control. Th
On 18.11.2022 15:11, Roger Pau Monne wrote:
> On one of my boxes when the HDMI cable is not plugged in the
> FrameBufferBase of the EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE structure is
> set to 0 by the firmware (while some of the other fields looking
> plausible).
>
> Such (bogus address) ends up mappe
On Mon, Nov 21, 2022 at 12:10 AM Juergen Gross wrote:
>
> On 19.11.22 09:28, Sander Eikelenboom wrote:
> > Hi Yu / Juergen,
Hi Sander / Juergen,
Thanks for the report and the analysis.
> > This night I got a dom0 kernel crash on my new Ryzen box running
> > Xen-unstable
> > and a Linux-6.1.0-r
flight 174871 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/174871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 173462
test-arm64-arm64-xl
On 18.11.2022 15:26, Roger Pau Monné wrote:
> On Fri, Nov 18, 2022 at 11:31:28AM +0100, Jan Beulich wrote:
>> Linux'es relatively new use of HVMOP_set_evtchn_upcall_vector has
>> exposed a problem with the marking of the respective vector as
>> pending: For quite some time Linux has been checking w
On 21.11.22 09:18, Yu Zhao wrote:
On Mon, Nov 21, 2022 at 12:10 AM Juergen Gross wrote:
On 19.11.22 09:28, Sander Eikelenboom wrote:
Hi Yu / Juergen,
Hi Sander / Juergen,
Thanks for the report and the analysis.
This night I got a dom0 kernel crash on my new Ryzen box running Xen-unstable
On 18.11.2022 15:27, Andrew Cooper wrote:
> On 18/11/2022 12:54, Jan Beulich wrote:
>> On 18.11.2022 13:33, Andrew Cooper wrote:
>>> On 18/11/2022 10:31, Jan Beulich wrote:
Linux'es relatively new use of HVMOP_set_evtchn_upcall_vector has
exposed a problem with the marking of the respecti
Hello,
This series aims to fix some shortcomings with the handling of ACPI
Processors objects when running as a Xen dom0.
First two patches fix the execution of the _PDC methods for all CPUs on
the system and not just the ones available to dom0, while also making
sure that the _PDC capabilities r
When running as a Xen dom0 the number of CPUs available to Linux can
be different from the number of CPUs present on the system, but in
order to properly fetch processor performance related data _PDC must
be executed on all the physical CPUs online on the system.
The current checks in processor_ph
The Processor _PDC buffer bits notify ACPI of the OS capabilities, and
so ACPI can adjust the return of other Processor methods taking the OS
capabilities into account.
When Linux is running as a Xen dom0, it's the hypervisor the entity
in charge of processor power management, and hence Xen needs
When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to
report the correct numbers of vCPUs that dom0 has, so the host MADT is
not provided to dom0. This creates issues when parsing the power and
performance related data from ACPI dynamic tables, as the ACPI
Processor UIDs found on
69 matches
Mail list logo
