Re: HVM/PVH Balloon crash

On 29.09.2021 17:31, Elliott Mitchell wrote: > On Wed, Sep 29, 2021 at 03:32:15PM +0200, Jan Beulich wrote: >> On 27.09.2021 00:53, Elliott Mitchell wrote: >>> (XEN) Xen call trace: >>> (XEN)[] R >>> arch/x86/mm/p2m.c#p2m_flush_table+0x240/0x260 >>> (XEN)[] S p2m_flush_nestedp2m+0x1c/0x30

[PATCH v3 00/11] PCI devices passthrough on Arm, part 2

From: Oleksandr Andrushchenko Hi, all! This is an assorted series of patches which aim is to make some further basis for PCI passthrough on Arm support. The series continues the work published earlier by Arm [1] and adds new helpers and clears the way for vPCI changes which will follow. RFC is

[PATCH v3 01/11] xen/arm: Fix dev_is_dt macro definition

From: Oleksandr Andrushchenko This macro is not currently used, but still has an error in it: a missing parenthesis. Fix this, so the macro is properly defined. Fixes: 6c5d3075d97e ("xen/arm: Introduce a generic way to describe device") Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Stefa

[PATCH v3 02/11] xen/arm: Add new device type for PCI

From: Oleksandr Andrushchenko Add new device type (DEV_PCI) to distinguish PCI devices from platform DT devices, so some drivers, like IOMMU, can handle PCI devices differently. Also add a helper which is when given a struct device returns the corresponding struct pci_dev which this device is a

[PATCH v3 03/11] xen/arm: Introduce pci_find_host_bridge_node helper

From: Oleksandr Andrushchenko Get host bridge node given a PCI device attached to it. This helper will be re-used for adding PCI devices by the subsequent patches. Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Oleksandr Tyshchenko --- Since v2: - !! dropped Stefano's r-b because of

[PATCH v3 04/11] xen/device-tree: Make dt_find_node_by_phandle global

From: Oleksandr Andrushchenko Make dt_find_node_by_phandle globally visible, so it can be re-used by other frameworks. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Stefano Stabellini --- xen/common/device_tree.c | 2 +- xen/include/xen/device_tree.h | 2 ++ 2 files changed, 3 inse

[PATCH v3 05/11] xen/arm: Mark device as PCI while creating one

From: Oleksandr Andrushchenko While adding a PCI device mark it as such, so other frameworks can distinguish it from DT devices. For that introduce an architecture defined helper which may perform additional initialization of the newly created PCI device. Signed-off-by: Oleksandr Andrushchenko

[PATCH v3 06/11] xen/domain: Call pci_release_devices() when releasing domain resources

From: Oleksandr Tyshchenko This is the very same that we already do for DT devices. Moreover, x86 already calls pci_release_devices(). Signed-off-by: Oleksandr Tyshchenko Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Stefano Stabellini --- Since v1: - re-wording in the commit message -

[PATCH v3 07/11] libxl: Allow removing PCI devices for all types of domains

From: Oleksandr Andrushchenko The PCI device remove path may now be used by PVH on ARM, so the assert is no longer valid. Signed-off-by: Oleksandr Andrushchenko Cc: Ian Jackson Cc: Juergen Gross --- tools/libs/light/libxl_pci.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/libs/

[PATCH v3 08/11] libxl: Only map legacy PCI IRQs if they are supported

From: Oleksandr Andrushchenko Arm's PCI passthrough implementation doesn't support legacy interrupts, but MSI/MSI-X. This can be the case for other platforms too. For that reason introduce a new CONFIG_PCI_SUPP_LEGACY_IRQ and add it to the CFLAGS and compile the relevant code in the toolstack onl

[PATCH v3 10/11] xen/arm: Do not map PCI ECAM and MMIO space to Domain-0's p2m

From: Oleksandr Andrushchenko PCI host bridges are special devices in terms of implementing PCI passthrough. According to [1] the current implementation depends on Domain-0 to perform the initialization of the relevant PCI host bridge hardware and perform PCI device enumeration. In order to achie

[PATCH v3 11/11] xen/arm: Process pending vPCI map/unmap operations

From: Oleksandr Andrushchenko vPCI may map and unmap PCI device memory (BARs) being passed through which may take a lot of time. For this those operations may be deferred to be performed later, so that they can be safely preempted. Currently this deferred processing is happening in common IOREQ

[PATCH v3 09/11] xen/arm: Setup MMIO range trap handlers for hardware domain

From: Oleksandr Andrushchenko In order for vPCI to work it needs to maintain guest and hardware domain's views of the configuration space. For example, BARs and COMMAND registers require emulation for guests and the guest view of the registers needs to be in sync with the real contents of the rel

Re: [PATCH v5] xen-pciback: allow compiling on other archs than x86

Hi, Juergen! Is it good to go or we need some other changes? Thank you, Oleksandr On 28.09.21 10:35, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Xen-pciback driver was designed to be built for x86 only. But it > can also be used by other architectures, e.g. Arm. > > Curre

Re: HVM/PVH Balloon crash

On 27.09.2021 00:53, Elliott Mitchell wrote: > On Wed, Sep 15, 2021 at 08:05:05AM +0200, Jan Beulich wrote: >> On 15.09.2021 04:40, Elliott Mitchell wrote: >>> On Tue, Sep 07, 2021 at 05:57:10PM +0200, Jan Beulich wrote: On 07.09.2021 17:03, Elliott Mitchell wrote: > Could be this system

Re: [PATCH v3 11/17] xen/arm: PCI host bridge discovery within XEN on ARM

On 29.09.2021 18:40, Stefano Stabellini wrote: > On Tue, 28 Sep 2021, Rahul Singh wrote: >> --- /dev/null >> +++ b/xen/arch/arm/pci/pci-host-generic.c >> @@ -0,0 +1,46 @@ >> +/* >> + * Based on Linux drivers/pci/controller/pci-host-common.c >> + * Based on Linux drivers/pci/controller/pci-host-gene

Re: [PATCH v3 12/17] xen/arm: Add support for Xilinx ZynqMP PCI host controller

On 29.09.2021 18:41, Stefano Stabellini wrote: > On Tue, 28 Sep 2021, Rahul Singh wrote: >> --- /dev/null >> +++ b/xen/arch/arm/pci/pci-host-zynqmp.c >> @@ -0,0 +1,63 @@ >> +/* >> + * Based on Linux drivers/pci/controller/pci-host-common.c >> + * Based on Linux drivers/pci/controller/pci-host-gener

[PATCH v3 00/11] PCI devices passthrough on Arm, part 3

From: Oleksandr Andrushchenko Hi, all! This patch series is focusing on vPCI and adds support for non-identity PCI BAR mappings which is required while passing through a PCI device to a guest. The highlights are: - Add relevant vpci register handlers when assigning PCI device to a domain and

[PATCH v3 01/11] vpci: Make vpci registers removal a dedicated function

From: Oleksandr Andrushchenko This is in preparation for dynamic assignment of the vpci register handlers depending on the domain: hwdom or guest. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Michal Orzel --- Since v1: - constify struct pci_dev where possible --- xen/drivers/vpci/vpci

Re: [PATCH v3 05/11] xen/arm: Mark device as PCI while creating one

On 30.09.2021 09:13, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > While adding a PCI device mark it as such, so other frameworks > can distinguish it from DT devices. > For that introduce an architecture defined helper which may perform > additional initialization of the new

[PATCH v3 02/11] vpci: Add hooks for PCI device assign/de-assign

From: Oleksandr Andrushchenko When a PCI device gets assigned/de-assigned some work on vPCI side needs to be done for that device. Introduce a pair of hooks so vPCI can handle that. Please note, that in the current design the error path is handled by the toolstack via XEN_DOMCTL_assign_device/XE

[PATCH v3 03/11] vpci/header: Move register assignments from init_bars

From: Oleksandr Andrushchenko This is in preparation for dynamic assignment of the vPCI register handlers depending on the domain: hwdom or guest. The need for this step is that it is easier to have all related functionality put at one place. When the subsequent patches add decisions on which han

[PATCH v3 04/11] vpci/header: Add and remove register handlers dynamically

From: Oleksandr Andrushchenko Add relevant vpci register handlers when assigning PCI device to a domain and remove those when de-assigning. This allows having different handlers for different domains, e.g. hwdom and other guests. Use stubs for guest domains for now. Signed-off-by: Oleksandr And

[PATCH v3 05/11] vpci/header: Implement guest BAR register handlers

From: Oleksandr Andrushchenko Emulate guest BAR register values: this allows creating a guest view of the registers and emulates size and properties probe as it is done during PCI device enumeration by the guest. ROM BAR is only handled for the hardware domain and for guest domains there is a st

[PATCH v3 06/11] vpci/header: Handle p2m range sets per BAR

From: Oleksandr Andrushchenko Instead of handling a single range set, that contains all the memory regions of all the BARs and ROM, have them per BAR. This is in preparation of making non-identity mappings in p2m for the MMIOs/ROM. Signed-off-by: Oleksandr Andrushchenko --- xen/drivers/vpci/h

[PATCH v3 07/11] vpci/header: program p2m with guest BAR view

From: Oleksandr Andrushchenko Take into account guest's BAR view and program its p2m accordingly: gfn is guest's view of the BAR and mfn is the physical BAR value as set up by the host bridge in the hardware domain. This way hardware doamin sees physical BAR values and guest sees emulated ones.

[PATCH v3 08/11] vpci/header: Emulate PCI_COMMAND register for guests

From: Oleksandr Andrushchenko Add basic emulation support for guests. At the moment only emulate PCI_COMMAND_INTX_DISABLE bit, the rest is not emulated yet and left as TODO. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Michal Orzel --- New in v2 --- xen/drivers/vpci/header.c | 35 +

[PATCH v3 11/11] xen/arm: Translate virtual PCI bus topology for guests

From: Oleksandr Andrushchenko There are three originators for the PCI configuration space access: 1. The domain that owns physical host bridge: MMIO handlers are there so we can update vPCI register handlers with the values written by the hardware domain, e.g. physical view of the registers vs g

[PATCH v3 10/11] vpci: Add initial support for virtual PCI bus topology

From: Oleksandr Andrushchenko Assign SBDF to the PCI devices being passed through with bus 0. The resulting topology is where PCIe devices reside on the bus 0 of the root complex itself (embedded endpoints). This implementation is limited to 32 devices which are allowed on a single PCI bus. Sign

[PATCH v3 09/11] vpci/header: Reset the command register when adding devices

From: Oleksandr Andrushchenko Reset the command register when passing through a PCI device: it is possible that when passing through a PCI device its memory decoding bits in the command register are already set. Thus, a guest OS may not write to the command register to update memory decoding, so

Re: [PATCH v3 11/11] xen/arm: Process pending vPCI map/unmap operations

On 30.09.2021 09:13, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > vPCI may map and unmap PCI device memory (BARs) being passed through which > may take a lot of time. For this those operations may be deferred to be > performed later, so that they can be safely preempted. >

Re: [PATCH v2 01/12] xen/trace: Don't over-read trace objects

On Mon, 2021-09-27 at 09:51 +0200, Jan Beulich wrote: > On 24.09.2021 16:51, Dario Faggioli wrote: > > On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote: > > > > > There is one buggy race record, TRC_RTDS_BUDGET_BURN.  As it must > > > remain > > > __packed (as cur_budget is misaligned), chan

Re: [PATCH v3 02/11] vpci: Add hooks for PCI device assign/de-assign

On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > When a PCI device gets assigned/de-assigned some work on vPCI side needs > to be done for that device. Introduce a pair of hooks so vPCI can handle > that. > > Please note, that in the current design the erro

[ovmf test] 165321: all pass - PUSHED

flight 165321 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/165321/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 442e46d3b6c1931b54111c92e0efb5a797bc622b baseline version: ovmf 46b4606ba23498d3d0e66

Re: [PATCH v3 02/11] vpci: Add hooks for PCI device assign/de-assign

On 30.09.21 11:21, Jan Beulich wrote: > On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> When a PCI device gets assigned/de-assigned some work on vPCI side needs >> to be done for that device. Introduce a pair of hooks so vPCI can handle >> that. >> >> P

Re: [PATCH v3 10/11] vpci: Add initial support for virtual PCI bus topology

On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Assign SBDF to the PCI devices being passed through with bus 0. This reads a little odd: If bus is already known (and I think you imply segment to also be known), it's only DF which get assigned. > The resul

Re: [PATCH v3 11/11] xen/arm: Translate virtual PCI bus topology for guests

On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: > --- a/xen/drivers/passthrough/pci.c > +++ b/xen/drivers/passthrough/pci.c > @@ -889,6 +889,31 @@ int pci_remove_virtual_device(struct domain *d, const > struct pci_dev *pdev) > xfree(vdev); > return 0; > } > + > +/* > + * Find the ph

Re: [PATCH v3 02/11] vpci: Add hooks for PCI device assign/de-assign

On 30.09.2021 10:45, Oleksandr Andrushchenko wrote: > On 30.09.21 11:21, Jan Beulich wrote: >> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: >>> @@ -1429,6 +1433,11 @@ static int assign_device(struct domain *d, u16 seg, >>> u8 bus, u8 devfn, u32 flag) >>> rc = hd->platform_ops->ass

[qemu-mainline test] 165319: regressions - FAIL

flight 165319 qemu-mainline real [real] flight 165328 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165319/ http://logs.test-lab.xenproject.org/osstest/logs/165328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH v3 02/11] vpci: Add hooks for PCI device assign/de-assign

On 30.09.21 12:06, Jan Beulich wrote: > On 30.09.2021 10:45, Oleksandr Andrushchenko wrote: >> On 30.09.21 11:21, Jan Beulich wrote: >>> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: @@ -1429,6 +1433,11 @@ static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32

[PATCH] xen/arm: Expose the PMU to the guests

Add parameter vpmu to xl domain configuration syntax to enable the access to PMU registers by disabling the PMU traps. This change does not expose the full PMU to the guest. Long term, we will want to at least expose the PMU interrupts, device-tree binding. For more use cases we will also need to

Re: [PATCH v3 10/11] vpci: Add initial support for virtual PCI bus topology

On 30.09.21 11:51, Jan Beulich wrote: > On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Assign SBDF to the PCI devices being passed through with bus 0. > This reads a little odd: If bus is already known (and I think you imply > segment to also be known)

Re: [PATCH v3 11/11] xen/arm: Translate virtual PCI bus topology for guests

On 30.09.21 11:53, Jan Beulich wrote: > On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: >> --- a/xen/drivers/passthrough/pci.c >> +++ b/xen/drivers/passthrough/pci.c >> @@ -889,6 +889,31 @@ int pci_remove_virtual_device(struct domain *d, const >> struct pci_dev *pdev) >> xfree(vdev); >

[libvirt test] 165325: regressions - FAIL

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

Re: [PATCH] xen/arm: Expose the PMU to the guests

Hi Michal, > On 30 Sep 2021, at 10:26, Michal Orzel wrote: > > Add parameter vpmu to xl domain configuration syntax > to enable the access to PMU registers by disabling > the PMU traps. > > This change does not expose the full PMU to the guest. > Long term, we will want to at least expose the P

x86/mm lock order enforcement

Hello, the issue pointed out in [1] (and hence the proposed fix in a reply) is actually pointing out a bigger problem, addressing of which may also invalidate that proposed fix. First, fundamentally any code path reaching p2m_pt_set_entry() (i.e. in particular any caller of p2m_set_entry()) is li

Re: [PATCH] xen/arm: Expose the PMU to the guests

On 30.09.2021 11:26, Michal Orzel wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -483,7 +483,7 @@ static int sanitise_domain_config(struct > xen_domctl_createdomain *config) > ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap | > XEN_DOMCTL_CDF_s3_integrity | XEN

Re: [PATCH v3 02/11] vpci: Add hooks for PCI device assign/de-assign

On 30.09.2021 11:21, Oleksandr Andrushchenko wrote: > On 30.09.21 12:06, Jan Beulich wrote: >> On 30.09.2021 10:45, Oleksandr Andrushchenko wrote: >>> On 30.09.21 11:21, Jan Beulich wrote: On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: > @@ -1429,6 +1433,11 @@ static int assign_device

Re: [PATCH v3 10/11] vpci: Add initial support for virtual PCI bus topology

On 30.09.2021 11:34, Oleksandr Andrushchenko wrote: > On 30.09.21 11:51, Jan Beulich wrote: >> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: >>> --- a/xen/drivers/passthrough/pci.c >>> +++ b/xen/drivers/passthrough/pci.c >>> @@ -831,6 +831,66 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn

Re: [PATCH v3 11/11] xen/arm: Translate virtual PCI bus topology for guests

On 30.09.2021 11:35, Oleksandr Andrushchenko wrote: > On 30.09.21 11:53, Jan Beulich wrote: >> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: >>> --- a/xen/drivers/passthrough/pci.c >>> +++ b/xen/drivers/passthrough/pci.c >>> @@ -889,6 +889,31 @@ int pci_remove_virtual_device(struct domain *d,

[linux-linus test] 165320: regressions - FAIL

flight 165320 linux-linus real [real] flight 165332 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/165320/ http://logs.test-lab.xenproject.org/osstest/logs/165332/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run

Re: [PATCH v3 10/11] vpci: Add initial support for virtual PCI bus topology

On 30.09.21 13:23, Jan Beulich wrote: > On 30.09.2021 11:34, Oleksandr Andrushchenko wrote: >> On 30.09.21 11:51, Jan Beulich wrote: >>> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -831,6 +831,66 @@

Re: [PATCH v3 02/11] vpci: Add hooks for PCI device assign/de-assign

On 30.09.21 13:14, Jan Beulich wrote: > On 30.09.2021 11:21, Oleksandr Andrushchenko wrote: >> On 30.09.21 12:06, Jan Beulich wrote: >>> On 30.09.2021 10:45, Oleksandr Andrushchenko wrote: On 30.09.21 11:21, Jan Beulich wrote: > On 30.09.2021 09:52, Oleksandr Andrushchenko wrote: >>

Re: [RFC PATCH 00/10] security: Introduce qemu_security_policy_taint() API

On Tue, Sep 14, 2021 at 01:30:27PM +, P J P wrote: > Hello Philippe, all > > >On Thursday, 9 September, 2021, 03:58:40 pm IST, Daniel P. Berrangé > > wrote: > >On Thu, Sep 09, 2021 at 01:20:14AM +0200, Philippe Mathieu-Daudé wrote: > >> This series is experimental! The goal is to better limit

Re: [PATCH] xen/arm: Expose the PMU to the guests

On 30/09/2021 10:26, Michal Orzel wrote: > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index 4b1e3028d2..4a75203b9f 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -2843,6 +2843,18 @@ Currently, only the "sbsa_uart" model is supported for > ARM.

Re: [PATCH v3 12/17] xen/arm: Add support for Xilinx ZynqMP PCI host controller

Hi Jan > On 30 Sep 2021, at 8:48 am, Jan Beulich wrote: > > On 29.09.2021 18:41, Stefano Stabellini wrote: >> On Tue, 28 Sep 2021, Rahul Singh wrote: >>> --- /dev/null >>> +++ b/xen/arch/arm/pci/pci-host-zynqmp.c >>> @@ -0,0 +1,63 @@ >>> +/* >>> + * Based on Linux drivers/pci/controller/pci-host

Re: [PATCH] xen/arm: Expose the PMU to the guests

Hi Andrew, On 30.09.2021 12:40, Andrew Cooper wrote: > On 30/09/2021 10:26, Michal Orzel wrote: >> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in >> index 4b1e3028d2..4a75203b9f 100644 >> --- a/docs/man/xl.cfg.5.pod.in >> +++ b/docs/man/xl.cfg.5.pod.in >> @@ -2843,6 +2843,18 @@ C

[PATCH v2 0/9] xen/x86: PVH Dom0 fixes and fallout adjustments

In order to try to debug hypervisor side breakage from XSA-378 I found myself urged to finally give PVH Dom0 a try. Sadly things didn't work quite as expected. In the course of investigating these issues I actually spotted one piece of PV Dom0 breakage as well, a fix for which is also included here

[PATCH v2 1/9] xen/x86: prevent PVH type from getting clobbered

Like xen_start_flags, xen_domain_type gets set before .bss gets cleared. Hence this variable also needs to be prevented from getting put in .bss, which is possible because XEN_NATIVE is an enumerator evaluating to zero. Any use prior to init_hvm_pv_info() setting the variable again would lead to wr

[PATCH v2 2/9] xen/x86: allow PVH Dom0 without XEN_PV=y

Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0 to a new XEN_PV_DOM0. (I'm not convinced all are really / should really be PV-specific, but for starters I've tried to be conservative.) For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so without x2APIC s

[PATCH v2 3/9] xen/x86: make "earlyprintk=xen" work better for PVH Dom0

The xen_hvm_early_write() path better wouldn't be taken in this case; while port 0xE9 can be used, the hypercall path is quite a bit more efficient. Put that first, as it may also work for DomU-s (see also xen_raw_console_write()). While there also bail from the function when the first domU_write_

[PATCH v2 4/9] xen/x86: allow "earlyprintk=xen" to work for PV Dom0

With preferred consoles "tty" and "hvc" announced as preferred, registering "xenboot" early won't result in use of the console: It also needs to be registered as preferred. Generalize this from being DomU- only so far. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- v2: Re-base. --- a

[PATCH v2 5/9] xen/x86: make "earlyprintk=xen" work for HVM/PVH DomU

xenboot_write_console() is dealing with these quite fine so I don't see why xenboot_console_setup() would return -ENOENT in this case. Adjust documentation accordingly. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentati

[PATCH v2 6/9] xen/x86: generalize preferred console model from PV to PVH Dom0

Without announcing hvc0 as preferred it won't get used as long as tty0 gets registered earlier. This is particularly problematic with there not being any screen output for PVH Dom0 when the screen is in graphics mode, as the necessary information doesn't get conveyed yet from the hypervisor. Follo

[PATCH v2 7/9] xen/x86: hook up xen_banner() also for PVH

This was effectively lost while dropping PVHv1 code. Move the function and arrange for it to be called the same way as done in PV mode. Clearly this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad check that was recently removed, as that's a PV-only feature. Since the string pointe

[PATCH v2 8/9] x86/PVH: adjust function/data placement

Two of the variables can live in .init.data, allowing the open-coded placing in .data to go away. Another "variable" is used to communicate a size value only to very early assembly code, which hence can be both const and live in .init.*. Additionally two functions were lacking __init annotations.

[PATCH v2 9/9] xen/x86: adjust data placement

Both xen_pvh and xen_start_flags get written just once early during init. Using the respective annotation then allows the open-coded placing in .data to go away. Additionally the former, like the latter, wants exporting, or else xen_pvh_domain() can't be used from modules. Signed-off-by: Jan Beul

[PATCH 0/6] xen/x86: PV boot speedup

The observed (by the human eye) performance difference of early boot between native and PV-on-Xen was just too large to not look into. As it turns out, gaining performance back wasn't all that difficult. While the series (re)introduces a small number of PTWR emulations on the boot path (from phys_

[PATCH 1/6] xen/x86: streamline set_pte_mfn()

In preparation for restoring xen_set_pte_init()'s original behavior of avoiding hypercalls, make set_pte_mfn() no longer use the standard set_pte() code path. That one is more complicated than the alternative of simply using an available hypercall directly. This way we can avoid introducing a fair

[PATCH 2/6] xen/x86: restore (fix) xen_set_pte_init() behavior

Commit f7c90c2aa400 ("x86/xen: don't write ptes directly in 32-bit PV guests") needlessly (and heavily) penalized 64-bit guests here: The majority of the early page table updates is to writable pages (which get converted to r/o only after all the writes are done), in particular those involved in bu

[PATCH 3/6] xen/x86: adjust xen_set_fixmap()

Using __native_set_fixmap() here means guaranteed trap-and-emulate instances the hypervisor has to deal with. Since the virtual address covered by the to be adjusted page table entry is easy to determine (and actually already gets obtained in a special case), simply use an available, easy to invoke

[PATCH 4/6] xen/x86: adjust handling of the L3 user vsyscall special page table

Marking the page tableas pinned without ever actually pinning is was probably an oversight in the first place. The main reason for the change is more subtle, though: The write of the one present entry each here and in the subsequently allocated L2 table engage a code path in the hypervisor which ex

[PATCH 5/6] xen/x86: there's no highmem anymore in PV mode

Considerations for it are a leftover from when 32-bit was still supported. Signed-off-by: Jan Beulich --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -306,10 +306,6 @@ static void __init xen_update_mem_tables BUG(); } - /* Update kernel mapping, but not f

[PATCH 6/6] xen/x86: restrict PV Dom0 identity mapping

When moving away RAM pages, there having been a mapping of those is not a proper indication that instead MMIO should be mapped there. At the point in time this effectively covers the low megabyte only. Mapping of that is, however, the job of init_mem_mapping(). Comparing the two one can also spot t

Re: [PATCH v2 7/9] xen/x86: hook up xen_banner() also for PVH

On 30.09.21 14:19, Jan Beulich wrote: This was effectively lost while dropping PVHv1 code. Move the function and arrange for it to be called the same way as done in PV mode. Clearly this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad check that was recently removed, as that's a P

Re: [PATCH v2 9/9] xen/x86: adjust data placement

On 30.09.21 14:21, Jan Beulich wrote: Both xen_pvh and xen_start_flags get written just once early during init. Using the respective annotation then allows the open-coded placing in .data to go away. Additionally the former, like the latter, wants exporting, or else xen_pvh_domain() can't be use

Re: [PATCH v5] xen-pciback: allow compiling on other archs than x86

On 28.09.21 09:35, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Xen-pciback driver was designed to be built for x86 only. But it can also be used by other architectures, e.g. Arm. Currently PCI backend implements multiple functionalities at a time, such as: 1. It is used as a d

Re: Xen 4.16 development update; request for regression bug reports

On 27.09.2021 16:24, Ian Jackson wrote: > The mainline development branch of Xen is has taken the first step > towards stabilisation for 4.16: new features not yet submitted, at > least in draft form, will now be deferred to the following release. > > We aim to make each Xen release as good as pos

Re: [PATCH v2 09/10] xen-blkfront: add error handling support for add_disk()

On 28.09.21 00:00, Luis Chamberlain wrote: We never checked for errors on device_add_disk() as this function returned void. Now that this is fixed, use the shiny new error handling. The function xlvbd_alloc_gendisk() typically does the unwinding on error on allocating the disk and creating the ta

Re: [PATCH v5 10/11] PCI: Replace pci_dev::driver usage by pci_dev::dev.driver

On 29/09/2021 17:44, Andrew Donnellan wrote: On 29/9/21 11:43 pm, Uwe Kleine-König wrote:> I'm not a huge fan either, I used it to keep the control flow as is and without introducing several calls to to_pci_driver. The whole code looks as follows: list_for_each_entry(afu_dev, &afu->phb-

Re: [PATCH v3 01/17] xen/pci: Refactor MSI code that implements MSI functionality within XEN

On 29.09.2021 18:56, Stefano Stabellini wrote: > On Tue, 28 Sep 2021, Rahul Singh wrote: >> On Arm, the initial plan is to only support GICv3 ITS which doesn't >> require us to manage the MSIs because the HW will protect against >> spoofing. Move the code under CONFIG_HAS_PCI_MSI flag to gate the c

[PATCH v4 0/3] arm/efi: Add dom0less support to UEFI boot

This serie introduces a way to start a dom0less setup when Xen is booting as EFI application. Using the device tree it's now possible to fetch from the disk and load in memory all the modules needed to start any domU defined in the DT. Dom0less for now is supported only by the arm architecture. Lu

[PATCH v4 2/3] arm/efi: Use dom0less configuration when using EFI boot

This patch introduces the support for dom0less configuration when using UEFI boot on ARM, it permits the EFI boot to continue if no dom0 kernel is specified but at least one domU is found. Introduce the new property "xen,uefi-binary" for device tree boot module nodes that are subnode of "xen,domai

[PATCH v4 1/3] arm/efi: Introduce xen,uefi-cfg-load DT property

Introduce the xen,uefi-cfg-load DT property of /chosen node for ARM whose presence decide whether to force the load of the UEFI Xen configuration file. The logic is that if any multiboot,module is found in the DT, then the xen,uefi-cfg-load property is used to see if the UEFI Xen configuration fil

[PATCH v4 3/3] arm/efi: load dom0 modules from DT using UEFI

Add support to load Dom0 boot modules from the device tree using the xen,uefi-binary property. Update documentation about that. Signed-off-by: Luca Fancellu --- Changes in v4: - Add check to avoid double definition of Dom0 ramdisk from cfg file and DT - Fix if conditions indentation in boot.c -

Re: [PATCH v4 2/3] arm/efi: Use dom0less configuration when using EFI boot

Hi Luca, > On 30 Sep 2021, at 15:28, Luca Fancellu wrote: > > This patch introduces the support for dom0less configuration > when using UEFI boot on ARM, it permits the EFI boot to > continue if no dom0 kernel is specified but at least one domU > is found. > > Introduce the new property "xen,ue

Re: [PATCH v4 3/3] arm/efi: load dom0 modules from DT using UEFI

Hi Luca, > On 30 Sep 2021, at 15:28, Luca Fancellu wrote: > > Add support to load Dom0 boot modules from > the device tree using the xen,uefi-binary property. > > Update documentation about that. > > Signed-off-by: Luca Fancellu Reviewed-by: Bertrand Marquis Cheers Bertrand > --- > Changes

Re: [PATCH v4 1/3] arm/efi: Introduce xen,uefi-cfg-load DT property

Hi Luca, > On 30 Sep 2021, at 15:28, Luca Fancellu wrote: > > Introduce the xen,uefi-cfg-load DT property of /chosen > node for ARM whose presence decide whether to force > the load of the UEFI Xen configuration file. > > The logic is that if any multiboot,module is found in > the DT, then the

Re: [PATCH v3 05/17] xen/arm: Add PHYSDEVOP_pci_device_* support for ARM

On 28.09.2021 20:18, Rahul Singh wrote: > Hardware domain is in charge of doing the PCI enumeration and will > discover the PCI devices and then will communicate to XEN via hyper > call PHYSDEVOP_pci_device_add(..) to add the PCI devices in XEN. > > Also implement PHYSDEVOP_pci_device_remove(..) t

Re: [PATCH v3 10/17] xen/arm: Add cmdline boot option "pci-passthrough = "

On 28.09.2021 20:18, Rahul Singh wrote: > @@ -62,8 +63,21 @@ static int __init acpi_pci_init(void) > } > #endif > > +/* > + * By default pci passthrough is disabled > + */ Nit: This is a single line comment. > +bool __read_mostly pci_passthrough_enabled = false; Nit: Unnecessary initializer.

Re: [PATCH v3 14/17] xen/arm: Enable the existing x86 virtual PCI support for ARM.

On 28.09.2021 20:18, Rahul Singh wrote: > The existing VPCI support available for X86 is adapted for Arm. > When the device is added to XEN via the hyper call > “PHYSDEVOP_pci_device_add”, VPCI handler for the config space > access is added to the Xen to emulate the PCI devices config space. > > A

Re: [PATCH V4 2/3] xen/arm: Add handling of extended regions for Dom0

> On 29 Sep 2021, at 23:52, Oleksandr Tyshchenko wrote: > > From: Oleksandr Tyshchenko > > The extended region (safe range) is a region of guest physical > address space which is unused and could be safely used to create > grant/foreign mappings instead of wasting real RAM pages from > the d

[adhoc test] 165337: all pass

[adhoc adhoc] harness 3a3089c9: mfi-common: Drop Linux dom0 i386 tests for newer Lin... 165337: all pass flight 165337 xen-unstable adhoc [adhoc] http://logs.test-lab.xenproject.org/osstest/logs/165337/ Perfect :-) All tests in this flight passed as required jobs: build-arm64-pvops

Re: [PATCH v2 2/3] include/public: add better interface description to usbif.h

> On 29 Sep 2021, at 08:46, Juergen Gross wrote: > > The PV USB protocol is poorly described. Add a more detailed > description to the usbif.h header file. > > Signed-off-by: Juergen Gross Reviewed-by: Luca Fancellu > --- > xen/include/public/io/usbif.h | 164 +

Re: [PATCH v2 1/3] include/public: add possible status values to usbif.h

> On 29 Sep 2021, at 08:46, Juergen Gross wrote: > > The interface definition of PV USB devices is lacking the specification > of possible values of the status field in a response. Those are > negative errno values as used in Linux, so they might differ in other > OS's. Specify them via approp

[XEN PATCH 2/2] automation: Add qemu to debian:stretch container for smoke test

From: Anthony PERARD We can add qemu into the container so that there's no need to install it everytime we run a test. Signed-off-by: Anthony PERARD --- Also, smoke tests stopped working as of today due to outdated root certificate, so container needs to be updated anyway. fatal: unable to

[XEN PATCH 1/2] automation: switch GitLab x86 smoke test to use PV 64bit binary

From: Anthony PERARD Xen is now built without CONFIG_PV32 by default and thus test jobs "qemu-smoke-x86-64-gcc" and "qemu-smoke-x86-64-clang" fails because they are using XTF's "test-pv32pae-example" which is an hello word 32bit PV guest. As we are looking for whether Xen boot or not with a quic

[XEN PATCH 0/2] Fixing gitlab CI tests

Patch series available in this git branch: https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git br.gitlab-pv32-test-fix-v1 Fixing tests due to CONFIG_PV32 missing. debian:stretch container needs updating due to certificate issue, so also install qemu in the container. Anthony PERARD

Re: [XEN PATCH 1/2] automation: switch GitLab x86 smoke test to use PV 64bit binary

On 30/09/2021 17:17, Anthony PERARD wrote: > From: Anthony PERARD > > Xen is now built without CONFIG_PV32 by default and thus test jobs > "qemu-smoke-x86-64-gcc" and "qemu-smoke-x86-64-clang" fails because > they are using XTF's "test-pv32pae-example" which is an hello word > 32bit PV guest. > >

Re: [XEN PATCH 1/2] automation: switch GitLab x86 smoke test to use PV 64bit binary

On Thu, Sep 30, 2021 at 05:20:31PM +0100, Andrew Cooper wrote: > On 30/09/2021 17:17, Anthony PERARD wrote: > > From: Anthony PERARD > > > > Xen is now built without CONFIG_PV32 by default and thus test jobs > > "qemu-smoke-x86-64-gcc" and "qemu-smoke-x86-64-clang" fails because > > they are using

  1   2   >