[Xen-devel] [xen-unstable test] 120767: regressions - FAIL

flight 120767 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/120767/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-livepatch 7 xen-boot fail REGR. vs. 120037

[Xen-devel] [xen-unstable-smoke test] 120854: tolerable all pass - PUSHED

flight 120854 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120854/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [PATCH v2 06/45] xen/arm: gic: Split the field state in gic_lr in 2 fields active and pending

On Fri, 16 Mar 2018, Julien Grall wrote: > On 16/03/2018 21:34, Stefano Stabellini wrote: > > On Thu, 15 Mar 2018, Andre Przywara wrote: > > > From: Julien Grall > > > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h > > > index daec51499c..c32861d4fa

Re: [Xen-devel] [PATCH v2 06/45] xen/arm: gic: Split the field state in gic_lr in 2 fields active and pending

On 16/03/2018 21:34, Stefano Stabellini wrote: On Thu, 15 Mar 2018, Andre Przywara wrote: From: Julien Grall diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h index daec51499c..c32861d4fa 100644 --- a/xen/include/asm-arm/gic.h +++

Re: [Xen-devel] [PATCH v2 08/45] ARM: GIC: extend LR read/write functions to cover EOI and source

On Thu, 15 Mar 2018, Andre Przywara wrote: > From: Julien Grall > > So far our LR read/write functions do not handle the EOI bit and the > source CPUID bits in an LR, because the current VGIC implementation does > not use them. > Extend the gic_lr data structure to hold

[Xen-devel] [xen-unstable-smoke test] 120851: tolerable all pass - PUSHED

flight 120851 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120851/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [PATCH v2 07/45] xen/arm: GIC: Only set pirq in the LR when hw_status is set

On Thu, 15 Mar 2018, Andre Przywara wrote: > From: Julien Grall > > The field pirq should only be valid when the virtual interrupt > is associated to a physical interrupt. > > This change will help to extend gic_lr for supporting specific virtual > interrupt field (e.g

Re: [Xen-devel] [PATCH v2 06/45] xen/arm: gic: Split the field state in gic_lr in 2 fields active and pending

On Thu, 15 Mar 2018, Andre Przywara wrote: > From: Julien Grall > > Mostly making the code nicer to read. > > Signed-off-by: Julien Grall > Reviewed-by: Andre Przywara > Signed-off-by: Andre Przywara

Re: [Xen-devel] [PATCH v2 05/45] xen/arm: gic: Use bool instead of uint8_t for the hw_status in gic_lr

On Thu, 15 Mar 2018, Andre Przywara wrote: > From: Julien Grall > > hw_status can only be 1 or 0. So convert to a bool. > > Signed-off-by: Julien Grall > Reviewed-by: Andre Przywara > Signed-off-by: Andre Przywara

Re: [Xen-devel] [PATCH v2 04/45] xen/arm: vgic: Override the group in lr everytime

On Thu, 15 Mar 2018, Andre Przywara wrote: > From: Julien Grall > > At the moment, write_lr is assuming the caller will set correctly the > group. However the group should always be 0 when the guest is using > vGICv2 and 1 for vGICv3. As the caller should not care about the

Re: [Xen-devel] [PATCH v2 02/45] ARM: Implement vcpu_kick()

On Thu, 15 Mar 2018, Andre Przywara wrote: > If we change something in a vCPU that affects its runnability or > otherwise needs the vCPU's attention, we might need to tell the scheduler > about it. > We are using this in one place (vIRQ injection) at the moment, but will > need this at more places

Re: [Xen-devel] [PATCH v2 01/45] ARM: VGIC: rename gic_event_needs_delivery()

On Thu, 15 Mar 2018, Andre Przywara wrote: > gic_event_needs_delivery() is not named very intuitively, especially > the gic_ prefix is somewhat misleading. > Rename it to vgic_vcpu_pending_irq(), which makes it clear that this > relates to the virtual GIC and is about interrupts. > Also add a VCPU

Re: [Xen-devel] [PATCH v2] xen/arm: p2m: Prevent deadlock when using memaccess

On Mon, 12 Mar 2018, julien.gr...@arm.com wrote: > From: Julien Grall > > Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt" > assumed the read-write lock can be taken recursively. However, this > assumption is wrong and will lead to deadlock when the lock

Re: [Xen-devel] [PATCH] xen/arm: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery

On Mon, 12 Mar 2018, julien.gr...@arm.com wrote: > From: Julien Grall > > A recent update to the ARM SMCCC_ARCH_WORKAROUND_1 specification (see [1]) > allows firmware to return a non zero, positive value, to describe that > although the mitigation is implemented at the

Re: [Xen-devel] [RFC] xen/arm: Restrict when a physical IRQ can be routed/removed from/to a domain

On Thu, 8 Mar 2018, julien.gr...@arm.com wrote: > From: Julien Grall > > Xen is currently allowing to route/remove an interrupt from/to the > domain while it is running. > > However, we never sync the virtual interrupt state to the physical > interrupt. This could lead to

Re: [Xen-devel] [PATCH] x86/entry: Fix passing 6th argument for compat hypercalls

On 16/03/18 19:55, Jason Andryuk wrote: > Commit ec05090403ef4d760fbe701e31afd0f0edc414d5 ("x86/entry: Erase guest > GPR state on entry to Xen") zero-ed %rbp, compat arg 6, but it is not > restored before passing to hypercalls. We need to pass the saved compat > arg 6 to the hypercall in r9, the

[Xen-devel] [PATCH] x86/entry: Fix passing 6th argument for compat hypercalls

Commit ec05090403ef4d760fbe701e31afd0f0edc414d5 ("x86/entry: Erase guest GPR state on entry to Xen") zero-ed %rbp, compat arg 6, but it is not restored before passing to hypercalls. We need to pass the saved compat arg 6 to the hypercall in r9, the 6th function argument. Signed-off-by: Jason

Re: [Xen-devel] [PATCH v3 3/4] libxl: Store PVH guest's e820 map in xc_dom_image

On 03/16/2018 02:20 PM, Roger Pau Monné wrote: > On Thu, Mar 15, 2018 at 02:35:17PM -0700, Maran Wilson wrote: >> From: Boris Ostrovsky >> >> We will later copy it to hvm_start_info. >> >> (Also remove stale comment claming that xc_dom_image.start_info_seg is >> only

Re: [Xen-devel] [RFC PATCH 00/30] Xen Q35 Bringup patches + support for PCIe Extended Capabilities for passed through devices

On Sat, Mar 17, 2018 at 03:34:58AM +1000, Alexey G wrote: > A gentle RFC-ping. > > Any thoughts on this? Regarding the feature as a whole. So far there > were responses mostly targeting individual patches, while I'd like to > hear about chosen approaches in general, whether the overall direction

[Xen-devel] [xen-unstable-smoke test] 120844: tolerable all pass - PUSHED

flight 120844 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120844/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

Re: [Xen-devel] [PATCH v3 2/4] libxl: Move libxl__arch_domain_construct_memmap() earlier

On 03/16/2018 02:12 PM, Roger Pau Monné wrote: > On Thu, Mar 15, 2018 at 02:35:16PM -0700, Maran Wilson wrote: >> From: Boris Ostrovsky >> >> Since hvm_start_info has now been expanded to include PVH guest's >> memory map (i.e. e820) we need to know size of this map by

Re: [Xen-devel] [PATCH v3 4/4] libxc: Pass e820 map to PVH guest via hvm_start_info

On Thu, Mar 15, 2018 at 02:35:18PM -0700, Maran Wilson wrote: > From: Boris Ostrovsky > > Signed-off-by: Boris Ostrovsky > Signed-off-by: Maran Wilson > --- > tools/libxc/xc_dom_x86.c | 30

Re: [Xen-devel] [RFC PATCH 00/30] Xen Q35 Bringup patches + support for PCIe Extended Capabilities for passed through devices

Hi Alexey, thanks for the ping. I think this is a good feature to have and I would like to check it in when it is ready. I spoke with Anthony and agreed that he will be reviewing it. Please be patient but we'll get there :-) On Sat, 17 Mar 2018, Alexey G wrote: > A gentle RFC-ping. > > Any

Re: [Xen-devel] [PATCH v3 3/4] libxl: Store PVH guest's e820 map in xc_dom_image

On Thu, Mar 15, 2018 at 02:35:17PM -0700, Maran Wilson wrote: > From: Boris Ostrovsky > > We will later copy it to hvm_start_info. > > (Also remove stale comment claming that xc_dom_image.start_info_seg is > only used for HVMlite guests) > > Signed-off-by: Boris

Re: [Xen-devel] [PATCH v3 2/4] libxl: Move libxl__arch_domain_construct_memmap() earlier

On Thu, Mar 15, 2018 at 02:35:16PM -0700, Maran Wilson wrote: > From: Boris Ostrovsky > > Since hvm_start_info has now been expanded to include PVH guest's > memory map (i.e. e820) we need to know size of this map by the time we > create dom->start_info_seg in

Re: [Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On Fri, Mar 16, 2018 at 10:00:54AM -0700, Maran Wilson wrote: > On 3/16/2018 4:11 AM, Roger Pau Monné wrote: > > On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote: > > >* 8 ++ > > >*| flags | SIF_xxx flags. > > >* 12 ++ > > > @@

Re: [Xen-devel] [PATCH v10 09/11] vpci/msi: add MSI handlers

On Fri, Mar 16, 2018 at 10:24:04AM -0600, Jan Beulich wrote: > >>> On 16.03.18 at 16:38, wrote: > > On Fri, Mar 16, 2018 at 09:05:44AM -0600, Jan Beulich wrote: > >> >>> On 16.03.18 at 15:34, wrote: > >> > vpci_remove_device is never called from the

[Xen-devel] [PATCH v1] xen/arm: Add MVEBU UART driver for Armada 3700 SoC

This patch adds driver for UART controller found on Armada 3700 SoC. There is no reference manuals available for 3700 SoC in public and this driver is derived by looking at Linux driver. https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c It allows XEN to boot on

Re: [Xen-devel] [RFC PATCH 00/30] Xen Q35 Bringup patches + support for PCIe Extended Capabilities for passed through devices

A gentle RFC-ping. Any thoughts on this? Regarding the feature as a whole. So far there were responses mostly targeting individual patches, while I'd like to hear about chosen approaches in general, whether the overall direction is correct (or not), etc. It's just RFC after all, not v11. :) I

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

On 16/03/2018 16:56, Julien Grall wrote: Hi Stefano, On 16/03/2018 16:33, Stefano Stabellini wrote: On Fri, 16 Mar 2018, Julien Grall wrote: Hi Stefano, On 15/03/18 23:52, Stefano Stabellini wrote: On Wed, 14 Mar 2018, Stefano Stabellini wrote: After looking at the test results, which

Re: [Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On 3/16/2018 4:11 AM, Roger Pau Monné wrote: On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote: The start info structure that is defined as part of the x86/HVM direct boot ABI and used for starting Xen PVH guests would be more versatile if it also included a way to pass information

[Xen-devel] [PATCH v2 2/4] x86/hvm: take a reference on ioreq server emulating domain

When an ioreq server is created the code currently stores the id of the emulating domain, but does not take a reference on that domain. This patch modifies the code to hold a reference for the lifetime of the ioreq server. Signed-off-by: Paul Durrant --- Cc: Jan Beulich

[Xen-devel] [PATCH v2 3/4] x86/hvm: re-structure some of the ioreq server look-up loops

This patch is a cosmetic re-structuring of some of the loops with look up an ioreq server based on target domain and server id. The restructuring is done separately here to ease review of a subsquent patch. Signed-off-by: Paul Durrant --- Cc: Jan Beulich

[Xen-devel] [PATCH v2 1/4] x86/hvm: stop passing explicit domid to hvm_create_ioreq_server()

Only in the legacy 'default server' case do we pass anything other than current->domain->domain_id, and in that case we pass the value of HVM_PARAM_DM_DOMAIN. The only known user of HVM_PARAM_DM_DOMAIN is qemu-trad, which always sets it to DOMID_SELF (ignoring the return value of

[Xen-devel] [PATCH v2 0/4] stricter ioreq server permissions checks

This series tightens up permissions checking on ioreq server control plane operations. Paul Durrant (4): x86/hvm: stop passing explicit domid to hvm_create_ioreq_server() x86/hvm: take a reference on ioreq server emulating domain x86/hvm: re-structure some of the ioreq server look-up loops

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

Hi Stefano, On 16/03/2018 16:33, Stefano Stabellini wrote: On Fri, 16 Mar 2018, Julien Grall wrote: Hi Stefano, On 15/03/18 23:52, Stefano Stabellini wrote: On Wed, 14 Mar 2018, Stefano Stabellini wrote: After looking at the test results, which are good for arm, and considering that master

Re: [Xen-devel] preparations for 4.9.2 and 4.7.5

On Fri, 16 Mar 2018, Julien Grall wrote: > Hi Stefano, > > On 15/03/18 23:52, Stefano Stabellini wrote: > > On Wed, 14 Mar 2018, Stefano Stabellini wrote: > > > After looking at the test results, which are good for arm, and > > > considering that master hasn't passed yet after 2 more days, I

Re: [Xen-devel] [PATCH] x86: correct EFLAGS.IF in SYSENTER frame

>>> On 16.03.18 at 16:42, wrote: > On 16/03/18 15:04, Jan Beulich wrote: > On 16.03.18 at 15:29, wrote: >>> Somewhat independently of this patch, I think we should assert that >>> flags are in the expected state in the return-to-guest

Re: [Xen-devel] [PATCH v10 09/11] vpci/msi: add MSI handlers

>>> On 16.03.18 at 16:38, wrote: > On Fri, Mar 16, 2018 at 09:05:44AM -0600, Jan Beulich wrote: >> >>> On 16.03.18 at 15:34, wrote: >> > vpci_remove_device is never called from the user-space test harness, >> > so it just needs to build, but not

[Xen-devel] [linux-4.1 test] 120763: regressions - FAIL

flight 120763 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/120763/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 118294 build-i386-pvops

Re: [Xen-devel] [PATCH v2 09/45] ARM: GIC: Allow tweaking the active and pending state of an IRQ

Hi, On 15/03/18 20:30, Andre Przywara wrote: > When playing around with hardware mapped, level triggered virtual IRQs, > there is the need to explicitly set the active or pending state of an > interrupt at some point. > To prepare the GIC for that, we introduce a set_active_state() and a >

Re: [Xen-devel] [PATCH] x86: correct EFLAGS.IF in SYSENTER frame

On 16/03/18 15:04, Jan Beulich wrote: On 16.03.18 at 15:29, wrote: >> On 16/03/18 14:13, Jan Beulich wrote: >>> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead") >>> moved the STI past the PUSHF. While this isn't an active problem (as we >>>

Re: [Xen-devel] [PATCH v10 09/11] vpci/msi: add MSI handlers

On Fri, Mar 16, 2018 at 09:05:44AM -0600, Jan Beulich wrote: > >>> On 16.03.18 at 15:34, wrote: > > vpci_remove_device is never called from the user-space test harness, > > so it just needs to build, but not necessarily be correct in that > > context. > > > > The test

Re: [Xen-devel] [PATCH v2 45/45] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

>>> On 16.03.18 at 16:13, wrote: > Hi, > > On 16/03/18 11:32, Jan Beulich wrote: > On 16.03.18 at 12:10, wrote: >>> On 16/03/18 10:48, Jan Beulich wrote: >>> On 15.03.18 at 21:30, wrote: > ---

[Xen-devel] [xen-4.7-testing test] 120748: regressions - FAIL

flight 120748 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/120748/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail REGR. vs. 119780 Tests which

Re: [Xen-devel] [PATCH v2 45/45] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

Hi, On 16/03/18 11:32, Jan Beulich wrote: On 16.03.18 at 12:10, wrote: >> On 16/03/18 10:48, Jan Beulich wrote: >> On 15.03.18 at 21:30, wrote: --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -19,6 +19,7 @@

Re: [Xen-devel] [PATCH v10 09/11] vpci/msi: add MSI handlers

>>> On 16.03.18 at 15:34, wrote: > On Fri, Mar 16, 2018 at 08:04:55AM -0600, Jan Beulich wrote: >> >>> On 16.03.18 at 14:30, wrote: >> > --- a/xen/drivers/vpci/vpci.c >> > +++ b/xen/drivers/vpci/vpci.c >> > @@ -47,6 +47,7 @@ void

Re: [Xen-devel] [PATCH] x86: correct EFLAGS.IF in SYSENTER frame

>>> On 16.03.18 at 15:29, wrote: > On 16/03/18 14:13, Jan Beulich wrote: >> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead") >> moved the STI past the PUSHF. While this isn't an active problem (as we >> force EFLAGS.IF to 1 before exiting to guest

Re: [Xen-devel] [PATCH v5 0/2] Containing AER unrecoverable errors

On Fri, 16 Mar 2018 10:32:10 -0400 Konrad Rzeszutek Wilk wrote: > On Tue, Mar 13, 2018 at 01:43:39PM -0500, Venu Busireddy wrote: > > This patch set is part of a set of patches that together allow containment > > of unrecoverable AER errors from PCIe devices assigned to

[Xen-devel] Passthrough a device to DomU on a ARM platform

Hi, I am new to Xen and trying to understand how does the VGA passthrough will work on a ARM based hardware. I have come across to a very limited information on this topic online. I will be very grateful if someone can point to the right direction. Kind Regards Naveed

Re: [Xen-devel] [PATCH v5 0/2] Containing AER unrecoverable errors

On 2018-03-16 10:32:10 -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 13, 2018 at 01:43:39PM -0500, Venu Busireddy wrote: > > This patch set is part of a set of patches that together allow containment > > of unrecoverable AER errors from PCIe devices assigned to guests in > > passthrough mode.

Re: [Xen-devel] [PATCH v10 09/11] vpci/msi: add MSI handlers

On Fri, Mar 16, 2018 at 08:04:55AM -0600, Jan Beulich wrote: > >>> On 16.03.18 at 14:30, wrote: > > --- a/xen/drivers/vpci/vpci.c > > +++ b/xen/drivers/vpci/vpci.c > > @@ -47,6 +47,7 @@ void vpci_remove_device(struct pci_dev *pdev) > > xfree(r); > > } > >

Re: [Xen-devel] [PATCH v5 0/2] Containing AER unrecoverable errors

On Tue, Mar 13, 2018 at 01:43:39PM -0500, Venu Busireddy wrote: > This patch set is part of a set of patches that together allow containment > of unrecoverable AER errors from PCIe devices assigned to guests in > passthrough mode. The containment is achieved by forcibly removing the > erring PCIe

Re: [Xen-devel] [PATCH] x86: correct EFLAGS.IF in SYSENTER frame

On 16/03/18 14:13, Jan Beulich wrote: > Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead") > moved the STI past the PUSHF. While this isn't an active problem (as we > force EFLAGS.IF to 1 before exiting to guest context), let's not risk > internal confusion by finding a PV guest

[Xen-devel] [qemu-mainline bisection] complete test-amd64-amd64-qemuu-nested-intel

branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-qemuu-nested-intel testid xen-boot/l1 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: qemuu

[Xen-devel] [xen-unstable-smoke test] 120838: tolerable all pass - PUSHED

flight 120838 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/120838/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm

[Xen-devel] [PATCH] x86: correct EFLAGS.IF in SYSENTER frame

Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead") moved the STI past the PUSHF. While this isn't an active problem (as we force EFLAGS.IF to 1 before exiting to guest context), let's not risk internal confusion by finding a PV guest frame with interrupts apparently off.

[Xen-devel] [PATCH 1/2] tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state

The data it stores is initialised and exclusively used within libxl__domain_make(), with the important details written back elsewhere by libxl__arch_domain_save_config(). Prepare xc_config on libxl__domain_make()'s stack, and drop the parameter. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH 0/2] tools/libxl: Fixes to domain building

This series is in preparation for passing more parameters via XEN_DOMCTL_createdomain. Andrew Cooper (2): tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state tools/libxl: Don't prepare or save xc_config when soft resetting a domain tools/libxl/libxl_create.c | 53

[Xen-devel] [PATCH 2/2] tools/libxl: Don't prepare or save xc_config when soft resetting a domain

xc_config is only used by xc_domain_create(), but by calling libxl__arch_domain_{prepare,save}_config() we clobber the real settings with the default settings. Move all data and calls relating to xc_domain_create() into the path which calls it. As far as I can tell, soft_reset has always been

Re: [Xen-devel] [PATCH v10 09/11] vpci/msi: add MSI handlers

>>> On 16.03.18 at 14:30, wrote: > --- a/xen/drivers/vpci/vpci.c > +++ b/xen/drivers/vpci/vpci.c > @@ -47,6 +47,7 @@ void vpci_remove_device(struct pci_dev *pdev) > xfree(r); > } > spin_unlock(>vpci->lock); > +xfree(pdev->vpci->msi); >

Re: [Xen-devel] [RFC] xen/arm: Restrict when a physical IRQ can be routed/removed from/to a domain

Gentle ping. The vGIC rework from Andre is based on that assumption. Cheers, On 08/03/18 15:24, julien.gr...@arm.com wrote: From: Julien Grall Xen is currently allowing to route/remove an interrupt from/to the domain while it is running. However, we never sync the

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

On 03/15/2018 03:45 PM, Boris Ostrovsky wrote: > On 03/15/2018 10:22 AM, Joao Martins wrote: >> All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and >> changing only the acpi_id. For processors which P-state coordination type >> is HW_ALL (0xFD) it is OK to upload bogus P-state

[Xen-devel] [PATCH v10 11/11] vpci/msix: add MSI-X handlers

Add handlers for accesses to the MSI-X message control field on the PCI configuration space, and traps for accesses to the memory region that contains the MSI-X table and PBA. This traps detect attempts from the guest to configure MSI-X interrupts and properly sets them up. Note that accesses to

[Xen-devel] [PATCH v10 05/11] pci: add support to size ROM BARs to pci_size_mem_bar

Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Julien Grall

[Xen-devel] [PATCH v10 09/11] vpci/msi: add MSI handlers

Add handlers for the MSI control, address, data and mask fields in order to detect accesses to them and setup the interrupts as requested by the guest. Note that the pending register is not trapped, and the guest can freely read/write to it. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v10 07/11] vpci/bars: add handlers to map the BARs

Introduce a set of handlers that trap accesses to the PCI BARs and the command register, in order to snoop BAR sizing and BAR relocation. The command handler is used to detect changes to bit 2 (response to memory space accesses), and maps/unmaps the BARs of the device into the guest p2m. A

[Xen-devel] [PATCH v10 00/11] vpci: PCI config space emulation

Hello, The following series contain an implementation of handlers for the PCI configuration space inside of Xen. This allows Xen to detect accesses to the PCI configuration space and react accordingly. Why is this needed? IMHO, there are two main points of doing all this emulation inside of Xen,

[Xen-devel] [PATCH v10 04/11] pci: split code to size BARs from pci_add_device

So that it can be called from outside in order to get the size of regular PCI BARs. This will be required in order to map the BARs from PCI devices into PVH Dom0 p2m. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich

[Xen-devel] [PATCH v10 08/11] x86/pt: mask MSI vectors on unbind

When a MSI device with per-vector masking capabilities is detected or added to Xen all the vectors are masked when initializing it. This implies that the first time the interrupt is bound to a domain it's masked. This however only applies to the first time the interrupt is bound because neither

[Xen-devel] [PATCH v10 01/11] vpci: introduce basic handlers to trap accesses to the PCI config space

This functionality is going to reside in vpci.c (and the corresponding vpci.h header), and should be arch-agnostic. The handlers introduced in this patch setup the basic functionality required in order to trap accesses to the PCI config space, and allow decoding the address and finding the

[Xen-devel] [PATCH v10 06/11] xen: introduce rangeset_consume_ranges

This function allows to iterate over a rangeset while removing the processed regions. This will be used in order to split processing of large memory areas when mapping them into the guest p2m. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu ---

[Xen-devel] [PATCH v10 10/11] vpci: add a priority parameter to the vPCI register initializer

This is needed for MSI-X, since MSI-X will need to be initialized before parsing the BARs, so that the header BAR handlers are aware of the MSI-X related holes and make sure they are not mapped in order for the trap handlers to work properly. Signed-off-by: Roger Pau Monné

[Xen-devel] [PATCH v10 03/11] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

So that MMCFG regions not present in the MCFG ACPI table can be added at run time by the hardware domain. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich Reviewed-by: Paul Durrant --- Cc: Jan Beulich

Re: [Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

>>> On 16.03.18 at 13:05, wrote: > I'd regard an address of zero and count > 0 as invalid. Indeed. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

>>> On 12.02.18 at 11:47, wrote: > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o > obj-y += hypercall.o > obj-y += i387.o > obj-y += i8259.o > +obj-y += iommu_op.o As mentioned in other contexts,

Re: [Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On 16/03/18 12:48, Jan Beulich wrote: On 16.03.18 at 12:37, wrote: >> On Fri, Mar 16, 2018 at 05:29:27AM -0600, Jan Beulich wrote: >> On 16.03.18 at 12:11, wrote: On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote: > @@

[Xen-devel] [PATCH v1 15/15] Enable Group0/1 Traps by default for Cavium ThunderX1

Enable trapping for Group0/1 register access when CONFIG_CAVIUM_ERRATUM_30115 is enabled. Signed-off-by: Manish Jaggi diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 473e26111f..6ffed6a634 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c

[Xen-devel] [PATCH v1 14/15] arm64: vgic-v3: Add ICV_AP(0/1)Rn_EL1 handler

This patch is a xen port of linux commit f9e7449c780f688bf61a13dfa8c344afeb4ad6e0. Add a handler for reading/writing the guest's view of the ICV_AP1Rn_EL1 registers. We just map them to the corresponding ICH_AP(0/1)Rn_EL2 registers. Signed-off-by: Manish Jaggi diff

[Xen-devel] [PATCH v1 13/15] arm64: vgic-v3: Add misc Group-0 handlers

This patch is ported to xen from linux commit: eab0b2dc4f6f34147e3d10da49ab8032e15dbea0 A number of Group-0 registers can be handled by the same accessors as that of Group-1, so let's add the required system register encodings and catch them in the dispatching function. Signed-off-by: Manish

[Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

This patchset is a Xen port of Marc's patchset. arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1] The current RFC patchset is a subset of [1], as it handleing only Group1 traps as a PoC. Most of the trap code is added in vsysreg.c. Trap handler function is kept independent of the usual

[Xen-devel] [PATCH v1 10/15] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

This patch is ported from linux to xen commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e (KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler) Add a handler for reading the guest's view of the ICV_HPPIR1_EL1 register. This is a simple parsing of the available LRs, extracting the highest available

[Xen-devel] [PATCH v1 09/15] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

This patch is ported to xen from linux commit b6f49035b4bf6e2709f2a5fed3107f5438c1fd02 Add a handler for writing the guest's view of the ICC_EOIR1_EL1 register. This involves dropping the priority of the interrupt, and deactivating it if required (EOImode == 0). Signed-off-by : Manish Jaggi

[Xen-devel] [PATCH v1 05/15] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

This patch is ported to xen from linux commit: f8b630bc542e0368886ae193d3519c832b270359 Add a handler for reading/writing the guest's view of the ICC_IGRPEN1_EL1 register, which is located in the ICH_VMCR_EL2.VENG1 field. Signed-off-by: Manish Jaggi diff --git

[Xen-devel] [PATCH v1 03/15] arm: Placeholder for handling Group0/1 traps for Cavium Erratum 30115

Since this is a SoC errata and trapping of certain group1 registers should not affect the normal flow. A new file vgic-v3-sr.c is added. Function vgic_v3_handle_cpuif_access is called from do_trap_guest_sync if ARM64_WORKAROUND_CAVIUM_30115 capability is found. A flag skip_hyp_tail is introduced

[Xen-devel] [PATCH v1 08/15] arm64: Add ICV_IAR1_EL1 handler

This patch is ported to xen from linux commit 132a324ab62fe4fb8d6dcc2ab4eddb0e93b69afe. Add a handler for reading the guest's view of the ICC_IAR1_EL1 register. This involves finding the highest priority Group-1 interrupt, checking against both PMR and the active group priority, activating the

[Xen-devel] [PATCH v1 11/15] arm64: vgic-v3: Add ICV_BPR0_EL1 handler

This patch is ported to xen from linux commit: 423de85a98c2b50715a0784a74f6124fbc0b1548 Add a handler for reading/writing the guest's view of the ICC_BPR0_EL1 register, which is located in the ICH_VMCR_EL2.BPR0 field. Signed-off-by: Manish Jaggi diff --git

[Xen-devel] [PATCH v1 12/15] arm64: vgic-v3: Add ICV_IGNREN0_EL1 handler

This patch is ported to xen from linux commit: fbc48a0011deb3d51cb657ca9c0f9083f41c0665 Add a handler for reading/writing the guest's view of the ICC_IGRPEN0_EL1 register, which is located in the ICH_VMCR_EL2.VENG0 field. Signed-off-by: Manish Jaggi diff --git

Re: [Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On Fri, Mar 16, 2018 at 05:48:09AM -0600, Jan Beulich wrote: > >>> On 16.03.18 at 12:37, wrote: > > On Fri, Mar 16, 2018 at 05:29:27AM -0600, Jan Beulich wrote: > >> >>> On 16.03.18 at 12:11, wrote: > >> > On Thu, Mar 15, 2018 at 02:33:09PM -0700,

[Xen-devel] [PATCH v1 04/15] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

This patch is ported to xen from linux commit d70c7b31a60f2458f35c226131f2a01a7a98b6cf Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1 register, which is located in the ICH_VMCR_EL2.BPR1 field. Signed-off-by: Manish Jaggi diff --git

[Xen-devel] [PATCH v1 06/15] arm64: Add accessors for the ICH_APxRn_EL2 registers

This patch is ported to xen from linux commit 63000dd8006dc987db31ba670edc23142ea91e01 As we're about to access the Active Priority registers a lot more, let's define accessors that take the register number as a parameter. This patch only has accessors, another patch will have register trap

[Xen-devel] [PATCH v1 02/15] arm64: Add config for Cavium Thunder erratum 30115

Some Cavium Thunder CPUs suffer a problem where a Xen guest may inadvertently cause the host kernel to quit receiving interrupts. This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will provide workaround. Signed-off-by: Manish Jaggi diff --git

[Xen-devel] [PATCH v1 01/15] arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family

Add MIDR values for Cavium ThunderX1 SoC family. ThunderX1, 81XX, 83XX. Signed-off-by: Manish Jaggi diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h index 65eb1071e1..62ad244785 100644 --- a/xen/include/asm-arm/processor.h +++

Re: [Xen-devel] [PATCH v3 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

>>> On 16.03.18 at 12:37, wrote: > On Fri, Mar 16, 2018 at 05:29:27AM -0600, Jan Beulich wrote: >> >>> On 16.03.18 at 12:11, wrote: >> > On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote: >> >> @@ -48,6 +49,15 @@ >> >> * 32

[Xen-devel] [PATCH 2/4] x86/hvm: take a reference on ioreq server emulating domain

When an ioreq server is created the code currently stores the id of the emulating domain, but does not take a reference on that domain. This patch modifies the code to hold a reference for the lifetime of the ioreq server. NOTE: For the default server only it is theoritically possible for the

[Xen-devel] [PATCH 4/4] x86/hvm: add stricter permissions checks to ioreq server control plane

There has always been an intention in the ioreq server API that only the domain that creates an ioreq server should be able to manipulate it. However, so far, nothing has enforced this. This means that two domains with DM_PRIV over a target domain can currently manipulate each others ioreq

[Xen-devel] [PATCH 1/4] x86/hvm: stop passing explicit domid to hvm_create_ioreq_server()

There are only two call-sites for this function: - The 'default' call site, which sets the is_default argument to true and passes the value of HVM_PARAM_DM_DOMAIN as domid. - The 'dm op' call site, which sets the is_default argument to false and passes current->domain->domain_id as domid.

[Xen-devel] [PATCH 0/4] stricter ioreq server permissions checks

This series tightens up permissions checking on ioreq server control plane operations. Paul Durrant (4): x86/hvm: stop passing explicit domid to hvm_create_ioreq_server() x86/hvm: take a reference on ioreq server emulating domain x86/hvm: re-structure some of the ioreq server look-up loops

[Xen-devel] [PATCH 3/4] x86/hvm: re-structure some of the ioreq server look-up loops

This patch is a cosmetic re-structuring of some of the loops with look up an ioreq server based on target domain and server id. The restructuring is done separately here to ease review of a subsquent patch. Signed-off-by: Paul Durrant --- Cc: Jan Beulich

Re: [Xen-devel] [PATCH 5/5] hvmloader: Use iPXE ROM loaded from a standalone file

On 16/03/18 11:26, Jan Beulich wrote: On 15.03.18 at 18:31, wrote: >> --- a/tools/firmware/hvmloader/config.h >> +++ b/tools/firmware/hvmloader/config.h >> @@ -33,6 +33,11 @@ struct bios_config { >> void (*create_mp_tables)(void); >> void

  1   2   >