[xen-4.14-testing test] 168013: tolerable FAIL - PUSHED

flight 168013 xen-4.14-testing real [real] flight 168019 xen-4.14-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168013/ http://logs.test-lab.xenproject.org/osstest/logs/168019/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): t

[linux-linus test] 168012: tolerable FAIL - PUSHED

flight 168012 linux-linus real [real] flight 168020 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168012/ http://logs.test-lab.xenproject.org/osstest/logs/168020/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-

Re: x86: insn-eval.c's use of native_store_gdt()

On Fri, Feb 04, 2022 at 03:13:52PM +0100, Jan Beulich wrote: > On 04.02.2022 15:08, Thomas Gleixner wrote: > > On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote: > >> On 30.11.2021 12:09, Jan Beulich wrote: > >>> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") > >>> which uncovere

Re: [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device

On Wed, Jan 26, 2022 at 10:56:39AM -0800, Stefano Stabellini wrote: > On Wed, 26 Jan 2022, Robin Murphy wrote: > > On 2022-01-26 15:09, Sergiy Kibrik wrote: > > > Hi Robin, > > > > > > > > > > > This could break Linux guests, since depending on the deferred probe > > > > timeout setting it could

[xen-unstable test] 168008: tolerable FAIL

flight 168008 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/168008/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit1 22 guest-start/debian.repeat fail pass in 168001 Tests which did not succeed, but

Re: Xen data from meta-virtualization layer

Hi Julien, Am 2022-02-05 00:29, schrieb Julien Grall: [..] But not a very user friendly one, though. I guess the first UART is disabled/removed by Xen? I haven't looked at how it is handled. Can't we search for other uarts with the same interrupt and disable these, too? Maybe conditionally by t

Re: Xen data from meta-virtualization layer

Hi Michael, On Fri, 4 Feb 2022 at 22:42, Michael Walle wrote: > Am 2022-02-04 22:11, schrieb Stefano Stabellini: > > On Fri, 4 Feb 2022, Michael Walle wrote: > >> > In regards to the reserved-memory regions, maybe we are not seeing them > >> > because Leo posted the host device tree, not the one

Re: Xen data from meta-virtualization layer

Hi Stefano, Am 2022-02-04 22:11, schrieb Stefano Stabellini: On Fri, 4 Feb 2022, Michael Walle wrote: > In regards to the reserved-memory regions, maybe we are not seeing them > because Leo posted the host device tree, not the one passed at runtime > from u-boot to Linux? > > If so, Leo, could

Re: [PATCH 04/16] x86/P2M: move map_domain_gfn() (again)

On Mon, Jul 5, 2021 at 5:07 PM Jan Beulich wrote: > The main user is the guest walking code, so move it back there; commit > 9a6787cc3809 ("x86/mm: build map_domain_gfn() just once") would perhaps > better have kept it there in the first place. This way it'll only get > built when it's actually n

Re: [PATCH 03/16] x86/P2M: drop a few CONFIG_HVM

On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote: > This is to make it easier to see which parts of p2m.c still aren't HVM- > specific: In one case the conditionals sat in an already guarded region, > while in the other case P2M_AUDIT implies HVM. > I think this would be much more easy to unders

Re: [PATCH 02/16] x86/P2M: introduce p2m_{add,remove}_page()

On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote: > p2m_add_page() is simply a rename from guest_physmap_add_entry(). > p2m_remove_page() then is its counterpart, despite rendering > guest_physmap_remove_page(). This way callers can use suitable pairs of > functions (previously violated by hvm/gr

Re: [PATCH 01/16] x86/P2M: rename p2m_remove_page()

On Mon, Jul 5, 2021 at 5:05 PM Jan Beulich wrote: > This is in preparation to re-using the original name. > > Signed-off-by: Jan Beulich > Hey Jan, This series overall looks good; thanks for taking this on. Functionally this patch looks good; just one question... --- a/xen/arch/x86/mm/p2m.c

Re: Xen data from meta-virtualization layer

On Fri, 4 Feb 2022, Michael Walle wrote: > > In regards to the reserved-memory regions, maybe we are not seeing them > > because Leo posted the host device tree, not the one passed at runtime > > from u-boot to Linux? > > > > If so, Leo, could you please boot Linux on native (no Xen) and get the >

[PATCH] xen/smp: Speed up on_selected_cpus()

cpumask_weight() is a horribly expensive way to find if no bits are set, made worse by the fact that the calculation is performed with the global call_lock held. Switch to using cpumask_empty() instead, which will short circuit as soon as it find any set bit in the cpumask. Signed-off-by: Andrew

Re: [PATCH v2] docs: document patch rules

Hi, On 03/02/2022 12:54, Juergen Gross wrote: +## The commit message + +The commit message is free text describing *why* the patch is done and +*how* the goal of the patch is achieved. A good commit message will describe +the current situation, the desired goal, and the way this goal is being +a

[xen-unstable-smoke test] 168011: tolerable all pass - PUSHED

flight 168011 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/168011/ 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

[libvirt test] 168006: regressions - FAIL

flight 168006 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/168006/ 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

[PATCH] x86/hvm: Fix boot on systems where HVM isn't available

c/s 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations to alt-call") went too far with dropping NULL function pointer checks. smp_callin() calls hvm_cpu_up() unconditionally. When the platform doesn't support HVM, hvm_enable() exits without filling in hvm_funcs, after which the

[linux-linus test] 168004: tolerable FAIL - PUSHED

flight 168004 linux-linus real [real] flight 168010 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168004/ http://logs.test-lab.xenproject.org/osstest/logs/168010/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Fri, Feb 04, 2022 at 02:43:07PM +, Oleksandr Andrushchenko wrote: > > > On 04.02.22 15:06, Roger Pau Monné wrote: > > On Fri, Feb 04, 2022 at 12:53:20PM +, Oleksandr Andrushchenko wrote: > >> > >> On 04.02.22 14:47, Jan Beulich wrote: > >>> On 04.02.2022 13:37, Oleksandr Andrushchenko

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.22 15:06, Roger Pau Monné wrote: > On Fri, Feb 04, 2022 at 12:53:20PM +, Oleksandr Andrushchenko wrote: >> >> On 04.02.22 14:47, Jan Beulich wrote: >>> On 04.02.2022 13:37, Oleksandr Andrushchenko wrote: On 04.02.22 13:37, Jan Beulich wrote: > On 04.02.2022 12:13, Roger Pau

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 04.02.22 16:30, Jan Beulich wrote: > On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: >> Reset the command register when assigning a PCI device to a guest: >> according to the PCI spec the PCI_COMMAND register is typically all 0's >> after reset. > It's not entirely clear to me whether sett

Re: [PATCH v6 10/13] vpci/header: reset the command register when adding devices

On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > Reset the command register when assigning a PCI device to a guest: > according to the PCI spec the PCI_COMMAND register is typically all 0's > after reset. It's not entirely clear to me whether setting the hardware register to zero is okay. Wha

Re: [PATCH v6 09/13] vpci/header: emulate PCI_COMMAND register for guests

On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > --- a/xen/drivers/vpci/header.c > +++ b/xen/drivers/vpci/header.c > @@ -454,6 +454,22 @@ static void cmd_write(const struct pci_dev *pdev, > unsigned int reg, > pci_conf_write16(pdev->sbdf, reg, cmd); > } > > +static void guest_cmd_

Re: [PATCH v6 04/13] vpci: restrict unhandled read/write operations for guests

On 04.02.22 16:11, Jan Beulich wrote: > On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: >> A guest can read and write those registers which are not emulated and >> have no respective vPCI handlers, so it can access the HW directly. > I don't think this describes the present situation. Or did

Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

On Fri, Feb 04, 2022 at 02:10:03PM +, Andrew Cooper wrote: > On 04/02/2022 13:46, Jan Beulich wrote: > > On 04.02.2022 14:34, Andrew Cooper wrote: > >> On 04/02/2022 13:09, Jan Beulich wrote: > >>> On 04.02.2022 13:12, Andrew Cooper wrote: > On 04/02/2022 08:31, Jan Beulich wrote: > >

Re: x86: insn-eval.c's use of native_store_gdt()

On 04.02.2022 15:08, Thomas Gleixner wrote: > On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote: >> On 30.11.2021 12:09, Jan Beulich wrote: >>> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") >>> which uncovered an issue with get_desc() trying to access the GDT, as >>> introduced

Re: [PATCH v6 04/13] vpci: restrict unhandled read/write operations for guests

On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > A guest can read and write those registers which are not emulated and > have no respective vPCI handlers, so it can access the HW directly. I don't think this describes the present situation. Or did I miss where devices can actually be exposed

[seabios test] 168003: tolerable FAIL - PUSHED

flight 168003 seabios real [real] flight 168009 seabios real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168003/ http://logs.test-lab.xenproject.org/osstest/logs/168009/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-

Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

On 04/02/2022 13:46, Jan Beulich wrote: > On 04.02.2022 14:34, Andrew Cooper wrote: >> On 04/02/2022 13:09, Jan Beulich wrote: >>> On 04.02.2022 13:12, Andrew Cooper wrote: On 04/02/2022 08:31, Jan Beulich wrote: > On 03.02.2022 19:10, Andrew Cooper wrote: >> It was Xen 4.14 where CPUI

Re: x86: insn-eval.c's use of native_store_gdt()

On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote: > On 30.11.2021 12:09, Jan Beulich wrote: >> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") >> which uncovered an issue with get_desc() trying to access the GDT, as >> introduced by 670f928ba09b ("x86/insn-eval: Add utility funct

Re: Xen data from meta-virtualization layer

Hi all, > + Zhiqiang Hou > > On Tue, 24 Nov 2020, Leo Krueger wrote: > > > >>> On Tue, 17 Nov 2020, Leo Krueger wrote: > > > Hi, > > > > > > I enabled CONFIG_HAS_ITS (what a stupid mistake by me to not set it > > > before...) but then had to add the following node to my device

[PATCH] x86/Intel: don't log bogus frequency range on Core/Core2 processors

Models 0F and 17 don't have PLATFORM_INFO documented. While it exists on at least model 0F, the information there doesn't match the scheme used on newer models (I'm observing a range of 700 ... 600 MHz reported on a Xeon E5345). Sadly the Enhanced Intel Core instance of the table entry is not self

Re: [PATCH v2] docs: document patch rules

On 03.02.2022 13:54, Juergen Gross wrote: > Add a document to describe the rules for sending a proper patch. > > As it contains all the information already being present in > docs/process/tags.pandoc remove that file. > > The "Reviewed-by:" and "Acked-by:" tags are expanded to allow an > optional

Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

On 04.02.2022 14:34, Andrew Cooper wrote: > On 04/02/2022 13:09, Jan Beulich wrote: >> On 04.02.2022 13:12, Andrew Cooper wrote: >>> On 04/02/2022 08:31, Jan Beulich wrote: On 03.02.2022 19:10, Andrew Cooper wrote: > It was Xen 4.14 where CPUID data was added to the migration stream, and

Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

On 04/02/2022 13:09, Jan Beulich wrote: > On 04.02.2022 13:12, Andrew Cooper wrote: >> On 04/02/2022 08:31, Jan Beulich wrote: >>> On 03.02.2022 19:10, Andrew Cooper wrote: It was Xen 4.14 where CPUID data was added to the migration stream, and 4.13 that we need to worry about with

Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

On 04.02.2022 13:12, Andrew Cooper wrote: > On 04/02/2022 08:31, Jan Beulich wrote: >> On 03.02.2022 19:10, Andrew Cooper wrote: >>> It was Xen 4.14 where CPUID data was added to the migration stream, and 4.13 >>> that we need to worry about with regards to compatibility. Xen 4.12 isn't >>> releva

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Fri, Feb 04, 2022 at 12:53:20PM +, Oleksandr Andrushchenko wrote: > > > On 04.02.22 14:47, Jan Beulich wrote: > > On 04.02.2022 13:37, Oleksandr Andrushchenko wrote: > >> > >> On 04.02.22 13:37, Jan Beulich wrote: > >>> On 04.02.2022 12:13, Roger Pau Monné wrote: > On Fri, Feb 04, 202

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.2022 13:53, Oleksandr Andrushchenko wrote: > > > On 04.02.22 14:47, Jan Beulich wrote: >> On 04.02.2022 13:37, Oleksandr Andrushchenko wrote: >>> >>> On 04.02.22 13:37, Jan Beulich wrote: On 04.02.2022 12:13, Roger Pau Monné wrote: > On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan

Re: [PATCH] xen: Modify domain_crash() to take a print string

On 04.02.2022 12:56, Andrew Cooper wrote: > On 03/02/2022 15:06, Jan Beulich wrote: >> On 03.02.2022 15:41, Andrew Cooper wrote: >>> On 03/02/2022 14:19, Jan Beulich wrote: On 03.02.2022 15:11, Andrew Cooper wrote: > On 03/02/2022 13:48, Julien Grall wrote: >> On 03/02/2022 13:38, Andr

Re: [PATCH] xen: Modify domain_crash() to take a print string

On 03.02.2022 14:38, Andrew Cooper wrote: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1693,11 +1693,8 @@ static void load_segments(struct vcpu *n) > put_guest(uregs->fs, esp - 5) | > put_guest(uregs->es, esp - 6) | > pu

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.22 14:47, Jan Beulich wrote: > On 04.02.2022 13:37, Oleksandr Andrushchenko wrote: >> >> On 04.02.22 13:37, Jan Beulich wrote: >>> On 04.02.2022 12:13, Roger Pau Monné wrote: On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan Beulich wrote: > On 04.02.2022 11:12, Oleksandr Andrushche

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.2022 13:37, Oleksandr Andrushchenko wrote: > > > On 04.02.22 13:37, Jan Beulich wrote: >> On 04.02.2022 12:13, Roger Pau Monné wrote: >>> On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan Beulich wrote: On 04.02.2022 11:12, Oleksandr Andrushchenko wrote: > On 04.02.22 11:15, Jan Beu

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.22 13:37, Jan Beulich wrote: > On 04.02.2022 12:13, Roger Pau Monné wrote: >> On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan Beulich wrote: >>> On 04.02.2022 11:12, Oleksandr Andrushchenko wrote: On 04.02.22 11:15, Jan Beulich wrote: > On 04.02.2022 09:58, Oleksandr Andrushchenko

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Fri, Feb 04, 2022 at 11:37:50AM +, Oleksandr Andrushchenko wrote: > > > On 04.02.22 13:13, Roger Pau Monné wrote: > > On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan Beulich wrote: > >> On 04.02.2022 11:12, Oleksandr Andrushchenko wrote: > >>> On 04.02.22 11:15, Jan Beulich wrote: > On

Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

On 04/02/2022 08:31, Jan Beulich wrote: > On 03.02.2022 19:10, Andrew Cooper wrote: >> It was Xen 4.14 where CPUID data was added to the migration stream, and 4.13 >> that we need to worry about with regards to compatibility. Xen 4.12 isn't >> relevant. >> >> Expand and correct the commentary. >>

Re: [PATCH] xen: Modify domain_crash() to take a print string

On 03/02/2022 15:06, Jan Beulich wrote: > On 03.02.2022 15:41, Andrew Cooper wrote: >> On 03/02/2022 14:19, Jan Beulich wrote: >>> On 03.02.2022 15:11, Andrew Cooper wrote: On 03/02/2022 13:48, Julien Grall wrote: > On 03/02/2022 13:38, Andrew Cooper wrote: >> diff --git a/xen/include/

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.22 13:13, Roger Pau Monné wrote: > On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan Beulich wrote: >> On 04.02.2022 11:12, Oleksandr Andrushchenko wrote: >>> On 04.02.22 11:15, Jan Beulich wrote: On 04.02.2022 09:58, Oleksandr Andrushchenko wrote: > On 04.02.22 09:52, Jan Beulich w

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.2022 12:13, Roger Pau Monné wrote: > On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan Beulich wrote: >> On 04.02.2022 11:12, Oleksandr Andrushchenko wrote: >>> On 04.02.22 11:15, Jan Beulich wrote: On 04.02.2022 09:58, Oleksandr Andrushchenko wrote: > On 04.02.22 09:52, Jan Beulich w

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

On 04.02.22 13:00, Julien Grall wrote: > > > On 04/02/2022 10:35, Oleksandr Andrushchenko wrote: >> >> >> On 04.02.22 11:57, Julien Grall wrote: >>> Hi, >>> >>> On 04/02/2022 09:47, Oleksandr Andrushchenko wrote: >> Could you please help me with the exact message you would like to see? >

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Fri, Feb 04, 2022 at 11:49:18AM +0100, Jan Beulich wrote: > On 04.02.2022 11:12, Oleksandr Andrushchenko wrote: > > On 04.02.22 11:15, Jan Beulich wrote: > >> On 04.02.2022 09:58, Oleksandr Andrushchenko wrote: > >>> On 04.02.22 09:52, Jan Beulich wrote: > On 04.02.2022 07:34, Oleksandr And

[xen-unstable test] 168001: tolerable FAIL - PUSHED

flight 168001 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/168001/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167994 test-armhf-armhf-libvirt 16 save

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

On 04/02/2022 10:35, Oleksandr Andrushchenko wrote: On 04.02.22 11:57, Julien Grall wrote: Hi, On 04/02/2022 09:47, Oleksandr Andrushchenko wrote: Could you please help me with the exact message you would like to see? Here a summary of the discussion (+ some my follow-up thoughts): is_

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On Fri, Feb 04, 2022 at 10:12:46AM +, Oleksandr Andrushchenko wrote: > Hi, Jan! > > On 04.02.22 11:15, Jan Beulich wrote: > > On 04.02.2022 09:58, Oleksandr Andrushchenko wrote: > >> On 04.02.22 09:52, Jan Beulich wrote: > >>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > @@ -285,

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.2022 11:12, Oleksandr Andrushchenko wrote: > On 04.02.22 11:15, Jan Beulich wrote: >> On 04.02.2022 09:58, Oleksandr Andrushchenko wrote: >>> On 04.02.22 09:52, Jan Beulich wrote: On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > @@ -285,6 +286,12 @@ static int modify_bars(con

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

On 04.02.22 11:57, Julien Grall wrote: > Hi, > > On 04/02/2022 09:47, Oleksandr Andrushchenko wrote: Could you please help me with the exact message you would like to see? >>> >>> Here a summary of the discussion (+ some my follow-up thoughts): >>> >>> is_memory_hole() was recently introduce

Re: [PATCH 2/3] x86/vmsi: add support for extended destination ID in address field

On 04.02.2022 10:54, Roger Pau Monné wrote: > On Fri, Feb 04, 2022 at 10:30:54AM +0100, Jan Beulich wrote: >> On 04.02.2022 10:23, Roger Pau Monné wrote: >>> On Mon, Jan 24, 2022 at 02:47:58PM +0100, Jan Beulich wrote: On 20.01.2022 16:23, Roger Pau Monne wrote: > --- a/xen/arch/x86/includ

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

Hi, Jan! On 04.02.22 11:15, Jan Beulich wrote: > On 04.02.2022 09:58, Oleksandr Andrushchenko wrote: >> On 04.02.22 09:52, Jan Beulich wrote: >>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: @@ -285,6 +286,12 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, boo

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

Hi, On 04/02/2022 09:47, Oleksandr Andrushchenko wrote: Could you please help me with the exact message you would like to see? Here a summary of the discussion (+ some my follow-up thoughts): is_memory_hole() was recently introduced on x86 (see commit 75cc460a1b8c "xen/pci: detect when BARs

Re: [PATCH 2/3] x86/vmsi: add support for extended destination ID in address field

On Fri, Feb 04, 2022 at 10:30:54AM +0100, Jan Beulich wrote: > On 04.02.2022 10:23, Roger Pau Monné wrote: > > On Mon, Jan 24, 2022 at 02:47:58PM +0100, Jan Beulich wrote: > >> On 20.01.2022 16:23, Roger Pau Monne wrote: > >>> --- a/xen/arch/x86/include/asm/msi.h > >>> +++ b/xen/arch/x86/include/as

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

On 04.02.22 11:41, Julien Grall wrote: > On 04/02/2022 09:01, Oleksandr Andrushchenko wrote: >> On 04.02.22 10:51, Julien Grall wrote: >>> Hi, >>> >>> On 04/02/2022 06:34, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add a stub for is_memory_hole which is required

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

On 04/02/2022 09:01, Oleksandr Andrushchenko wrote: On 04.02.22 10:51, Julien Grall wrote: Hi, On 04/02/2022 06:34, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add a stub for is_memory_hole which is required for PCI passthrough on Arm. Signed-off-by: Oleksandr Andrushchenko

Re: [PATCH v3 2/2] x86/mm: tidy XENMEM_{get,set}_pod_target handling

On 04.02.2022 10:28, Roger Pau Monné wrote: > On Wed, Feb 02, 2022 at 04:29:37PM +0100, Jan Beulich wrote: >> On 02.02.2022 16:14, Roger Pau Monné wrote: >>> On Tue, Jan 04, 2022 at 10:41:53AM +0100, Jan Beulich wrote: Do away with the "pod_target_out_unlock" label. In particular by folding >>

Re: [PATCH 2/3] x86/vmsi: add support for extended destination ID in address field

On 04.02.2022 10:23, Roger Pau Monné wrote: > On Mon, Jan 24, 2022 at 02:47:58PM +0100, Jan Beulich wrote: >> On 20.01.2022 16:23, Roger Pau Monne wrote: >>> --- a/xen/arch/x86/include/asm/msi.h >>> +++ b/xen/arch/x86/include/asm/msi.h >>> @@ -54,6 +54,7 @@ >>> #define MSI_ADDR_DEST_ID_SHIFT

Re: [PATCH v3 2/2] x86/mm: tidy XENMEM_{get,set}_pod_target handling

On Wed, Feb 02, 2022 at 04:29:37PM +0100, Jan Beulich wrote: > On 02.02.2022 16:14, Roger Pau Monné wrote: > > On Tue, Jan 04, 2022 at 10:41:53AM +0100, Jan Beulich wrote: > >> Do away with the "pod_target_out_unlock" label. In particular by folding > >> if()-s, the logic can be expressed with less

Re: [PATCH] x86/Xen: streamline (and fix) PV CPU enumeration

On 01.02.22 11:57, Jan Beulich wrote: This started out with me noticing that "dom0_max_vcpus=" with larger than the number of physical CPUs reported through ACPI tables would not bring up the "excess" vCPU-s. Addressing this is the primary purpose of the change; CPU maps handling is being tidied

Re: x86: insn-eval.c's use of native_store_gdt()

On 30.11.2021 12:09, Jan Beulich wrote: > I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") > which uncovered an issue with get_desc() trying to access the GDT, as > introduced by 670f928ba09b ("x86/insn-eval: Add utility function to > get segment descriptor"). When running in a P

Re: [PATCH v2] Improve docs for IOCTL_GNTDEV_MAP_GRANT_REF

On 31.01.22 18:23, Demi Marie Obenour wrote: The current implementation of gntdev guarantees that the first call to IOCTL_GNTDEV_MAP_GRANT_REF will set @index to 0. This is required to use gntdev for Wayland, which is a future desire of Qubes OS. Additionally, requesting zero grants results in a

Re: [PATCH v2] xen: update missing ioctl magic numers documentation

On 31.01.22 17:19, Randy Dunlap wrote: Add missing ioctl "magic numbers" for various Xen interfaces (xenbus_dev.h, gntalloc.h, gntdev.h, and privcmd.h). Signed-off-by: Randy Dunlap Pushed to xen/tip.git for-linus-5.17a Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key

Re: [PATCH] xen: xenbus_dev.h: delete incorrect file name

On 30.01.22 20:17, Randy Dunlap wrote: It is better/preferred not to include file names in source files because (a) they are not needed and (b) they can be incorrect, so just delete this incorrect file name. Signed-off-by: Randy Dunlap Pushed to xen/tip.git for-linus-5.17a Juergen OpenPG

Re: [PATCH 2/3] x86/vmsi: add support for extended destination ID in address field

On Mon, Jan 24, 2022 at 02:47:58PM +0100, Jan Beulich wrote: > On 20.01.2022 16:23, Roger Pau Monne wrote: > > --- a/xen/arch/x86/include/asm/msi.h > > +++ b/xen/arch/x86/include/asm/msi.h > > @@ -54,6 +54,7 @@ > > #define MSI_ADDR_DEST_ID_SHIFT 12 > > #define MSI_ADDR_DEST_ID_MAS

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.2022 09:58, Oleksandr Andrushchenko wrote: > On 04.02.22 09:52, Jan Beulich wrote: >> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: >>> @@ -285,6 +286,12 @@ static int modify_bars(const struct pci_dev *pdev, >>> uint16_t cmd, bool rom_only) >>> continue; >>>

[qemu-mainline test] 168000: tolerable FAIL - PUSHED

flight 168000 qemu-mainline real [real] flight 168007 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/168000/ http://logs.test-lab.xenproject.org/osstest/logs/168007/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-am

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

Hi, Julien! On 04.02.22 10:51, Julien Grall wrote: > Hi, > > On 04/02/2022 06:34, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Add a stub for is_memory_hole which is required for PCI passthrough >> on Arm. >> >> Signed-off-by: Oleksandr Andrushchenko >> >> --- >> Cc: Jul

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

Hi, Jan! On 04.02.22 09:52, Jan Beulich wrote: > On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: >> @@ -285,6 +286,12 @@ static int modify_bars(const struct pci_dev *pdev, >> uint16_t cmd, bool rom_only) >> continue; >> } >> >> +spin_lock(&tmp->vpci_lock

Re: [PATCH v6 01/13] xen/pci: arm: add stub for is_memory_hole

Hi, On 04/02/2022 06:34, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add a stub for is_memory_hole which is required for PCI passthrough on Arm. Signed-off-by: Oleksandr Andrushchenko --- Cc: Julien Grall Cc: Stefano Stabellini --- New in v6 --- xen/arch/arm/mm.c | 6 ++

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

On 04.02.2022 09:13, Oleksandr Andrushchenko wrote: > On 04.02.22 09:52, Jan Beulich wrote: >> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: >> >> At the first glance this simply looks like another unjustified (in the >> description) change, as you're not converting anything here but you >> a

Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

On 03.02.2022 19:10, Andrew Cooper wrote: > It was Xen 4.14 where CPUID data was added to the migration stream, and 4.13 > that we need to worry about with regards to compatibility. Xen 4.12 isn't > relevant. > > Expand and correct the commentary. > > Fixes: 111c8c33a8a1 ("x86/cpuid: do not expa

Re: [PATCH v6 12/13] xen/arm: translate virtual PCI bus topology for guests

Hi, Jan! On 04.02.22 09:56, Jan Beulich wrote: > On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: >> --- a/xen/drivers/vpci/vpci.c >> +++ b/xen/drivers/vpci/vpci.c >> @@ -168,6 +168,35 @@ static void vpci_remove_virtual_device(struct domain *d, >> pdev->vpci->guest_sbdf.sbdf = ~0; >> }

Re: [PATCH v6 03/13] vpci: move lock outside of struct vpci

Hi, Jan! On 04.02.22 09:52, Jan Beulich wrote: > On 04.02.2022 07:34, Oleksandr Andrushchenko wrote: > > At the first glance this simply looks like another unjustified (in the > description) change, as you're not converting anything here but you > actually add locking (and I realize this was there