Re: [Xen-devel] [PATCH v2 2/3] sndif: Add explicit back and front synchronization

On 03/15/2018 10:17 PM, Konrad Rzeszutek Wilk wrote: + ** + *Back to front events delivery + ** + * In order to deliver

Re: [Xen-devel] [PATCH v3 5/6] x86/XPTI: reduce .text.entry

>>> On 15.03.18 at 18:10, wrote: > On 13/03/18 13:50, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_64/entry.S >> +++ b/xen/arch/x86/x86_64/entry.S >> @@ -14,8 +14,6 @@ >> #include >> #include >> >> -.section .text.entry, "ax", @progbits >> - >> /* %rbx:

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

>>> On 15.03.18 at 17:33, wrote: > On Thu, Mar 15, 2018 at 06:45:58AM -0600, Jan Beulich wrote: >> >>> On 15.03.18 at 13:01, wrote: >> > On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan Beulich wrote: >> >> >>> On 14.03.18 at 15:04,

Re: [Xen-devel] [PATCH 7/7] xen/mm: Clean up share_xen_page_with_guest() API

>>> On 15.03.18 at 21:25, wrote: > On 13/03/18 14:39, Jan Beulich wrote: > On 13.03.18 at 13:28, wrote: >>> On Fri, Mar 09, 2018 at 01:18:42PM +, Andrew Cooper wrote: --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@

Re: [Xen-devel] [PATCH] xen/x86: Implement enable_nmis() in C

>>> On 15.03.18 at 18:07, wrote: > On 15/03/18 17:02, Jan Beulich wrote: > On 15.03.18 at 17:43, wrote: >>> +static inline void enable_nmis(void) >>> +{ >>> +unsigned long tmp; >>> + >>> +asm volatile ( "mov %%rsp, %[sp] \n\t"

Re: [Xen-devel] [PATCH 5/7] x86/domain: Optimise the order of actions in arch_domain_create()

>>> On 15.03.18 at 21:15, wrote: > On 09/03/18 16:54, Jan Beulich wrote: > On 09.03.18 at 14:18, wrote: >>> --- a/xen/arch/x86/domain.c >>> +++ b/xen/arch/x86/domain.c >>> @@ -430,20 +430,37 @@ int arch_domain_create(struct domain *d,

Re: [Xen-devel] Xen ARM Community Call Wednesday 4th April 4PM UTC

On 16/03/18 00:08, Stefano Stabellini wrote: Hi all, Hi Stefano, I suggest to have the next community call on Wednesday 4th April 4PM UTC. Keep in mind that due to Daylight Savings Time 4PM UTC is the usual time slot: 9AM California, 5PM UK. Does it work for everybody? This works for me.

Re: [Xen-devel] [PATCH 3/7] iommu: push use of type-safe BFN and MFN into iommu_ops

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 15 March 2018 16:16 > To: Paul Durrant > Cc: Suravee Suthikulpanit ; Andrew > Cooper ; Kevin Tian ; >

Re: [Xen-devel] [PATCH 2/7] iommu: make use of type-safe BFN and MFN in exported functions

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 15 March 2018 15:45 > To: Paul Durrant > Cc: Julien Grall ; Andrew Cooper > ; Wei Liu ; George > Dunlap

Re: [Xen-devel] [PATCH 4/7] vtd: add lookup_page method to iommu_ops

>>> On 16.03.18 at 11:19, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 15 March 2018 16:54 >> >> >>> On 12.02.18 at 11:47, wrote: >> > This patch adds a new method to the VT-d IOMMU implementation to find >> the >> > MFN

Re: [Xen-devel] [PATCH 1/7] iommu: introduce the concept of BFN...

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 15 March 2018 13:40 > To: Paul Durrant > Cc: Suravee Suthikulpanit ; Julien Grall > ; Kevin Tian ; Stefano >

Re: [Xen-devel] [PATCH v3 1/6] x86: NOP out XPTI entry/exit code when it's not in use

On 16/03/18 10:46, Jan Beulich wrote: On 15.03.18 at 20:44, wrote: >> On 13/03/18 13:47, Jan Beulich wrote: >>> Introduce a synthetic feature flag to use alternative instruction >>> patching to NOP out all code on entry/exit paths. Having NOPs here is >>> generally

Re: [Xen-devel] [PATCH 1/7] iommu: introduce the concept of BFN...

>>> On 16.03.18 at 11:31, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: 15 March 2018 13:40 >> >> >>> On 12.02.18 at 11:47, wrote: >> > --- a/xen/include/xen/iommu.h >> > +++ b/xen/include/xen/iommu.h >> > @@ -23,11 +23,15 @@

Re: [Xen-devel] [PATCH 4/7] vtd: add lookup_page method to iommu_ops

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 16 March 2018 10:29 > To: Paul Durrant > Cc: Kevin Tian ; xen-devel@lists.xenproject.org > Subject: RE: [PATCH 4/7] vtd: add lookup_page method to iommu_ops > > >>>

Re: [Xen-devel] [PATCH v3 1/6] x86: NOP out XPTI entry/exit code when it's not in use

>>> On 16.03.18 at 11:37, wrote: > I think we should do some performance testing to decide whether it makes > sense to take the patch or not. After all I don't see a reason to punish > AMD processors for INTEL's bugs. And I've already found out that some > branches in interrupt

Re: [Xen-devel] [PATCH v2 17/45] Add list_sort() routine from Linux

>>> On 15.03.18 at 21:30, wrote: > This pulls in Linux' list_sort.c, which is a merge sort implementation > for linked lists. Apart from adding a full featured license header and > adjusting the #include file, nothing has been changed in this code. Please mention the

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

>>> On 15.03.18 at 21:30, wrote: > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -19,6 +19,7 @@ obj-y += keyhandler.o > obj-$(CONFIG_KEXEC) += kexec.o > obj-$(CONFIG_KEXEC) += kimage.o > obj-y += lib.o > +obj-y += list_sort.o Why here rather than in

[Xen-devel] [linux-next test] 120739: regressions - FAIL

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

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

Hi, Daniel! Sorry, if I strip the patch too much below. On 03/16/2018 10:23 AM, Daniel Vetter wrote: S-o-b line went missing here :-) will restore it back ;) I've read through it, 2 actual review comments (around hot-unplug and around the error recovery for failed flips), a few bikesheds,

Re: [Xen-devel] [PATCH v3 4/4] xen/libxc: suppress direct access to Credit1's migration delay

>>> On 15.03.18 at 18:51, wrote: > Removes special purpose access to Credit1 vCPU > migration delay parameter. > > This fixes a build breakage, occuring when Xen > is configured with SCHED_CREDIT=n. > > Signed-off-by: Dario Faggioli > Acked-by: Wei Liu

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

Hi Andre, On 15/03/18 20:30, 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

Re: [Xen-devel] [PATCH 4/7] x86/domain: Remove unused parameters from {hvm, pv}_domain_initialise()

>>> On 15.03.18 at 21:09, wrote: > On 13/03/18 12:05, Roger Pau Monné wrote: >> Maybe this could be: >> >> if ( is_idle_domain(d) ) >> ... >> else >> { >> rc = is_hvm_domain(d) ? hvm_domain_initialise(d) >> : pv_domain_initialise(d); >>

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

Hi Andre, On 15/03/18 20:30, 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

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

>>> On 15.03.18 at 22:33, 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 about the memory map to the guest. This >

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

On Fri, Mar 16, 2018 at 01:36:53AM -0600, Jan Beulich wrote: > >>> On 15.03.18 at 17:33, wrote: > > On Thu, Mar 15, 2018 at 06:45:58AM -0600, Jan Beulich wrote: > >> >>> On 15.03.18 at 13:01, wrote: > >> > On Wed, Mar 14, 2018 at 11:04:00AM -0600, Jan

Re: [Xen-devel] [PATCH 4/7] vtd: add lookup_page method to iommu_ops

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 15 March 2018 16:54 > To: Paul Durrant > Cc: Kevin Tian ; xen-devel@lists.xenproject.org > Subject: Re: [PATCH 4/7] vtd: add lookup_page method to iommu_ops > > >>>

Re: [Xen-devel] [PATCH 7/7] xen/mm: Clean up share_xen_page_with_guest() API

On 16/03/2018 07:43, Jan Beulich wrote: On 15.03.18 at 21:25, wrote: >> On 13/03/18 14:39, Jan Beulich wrote: >> On 13.03.18 at 13:28, wrote: On Fri, Mar 09, 2018 at 01:18:42PM +, Andrew Cooper wrote: > ---

Re: [Xen-devel] [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

On Tue, Mar 13, 2018 at 06:21:05PM +0200, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Add support for Xen para-virtualized frontend display driver. > Accompanying backend [1] is implemented as a user-space application > and its helper

Re: [Xen-devel] [PATCH v3 1/6] x86: NOP out XPTI entry/exit code when it's not in use

>>> On 15.03.18 at 20:44, wrote: > On 13/03/18 13:47, Jan Beulich wrote: >> Introduce a synthetic feature flag to use alternative instruction >> patching to NOP out all code on entry/exit paths. Having NOPs here is >> generally better than using conditional branches. >>

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 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] 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

[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 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 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 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 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

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] [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] 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] 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] 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 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] [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] [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

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

[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] 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

[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

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 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

[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 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); > > } > >

[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

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

[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

[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] [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

[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.

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 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 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] [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

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 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 @@

[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 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 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

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] [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

>>> 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: > ---

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 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

[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] 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

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] 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] [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] [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

[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 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

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 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 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

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

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

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 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 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 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 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

[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 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 +++

  1   2   >