Re: [Xen-devel] [OSSTEST PATCH] arm64, armhf: Use dtuart for console by default

Hi Ian, On 26/05/17 11:44, Ian Jackson wrote: We don't want to have to set a host property for each ARM host. Julien writes: This command line should always work for arm64. If the device-tree does not provide the property then it is a bug. We want the command NIT: "does not provide the

[Xen-devel] [linux-3.18 test] 109754: tolerable FAIL - PUSHED

flight 109754 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109754/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 4 host-ping-check-native fail in 109744 pass in 109754 test-amd64-i386-libvirt

Re: [Xen-devel] xl create failure on arm64 with XEN 4.9rc6

On 26/05/17 01:37, Feng Kan wrote: On Thu, May 25, 2017 at 12:56 PM, Julien Grall wrote: (CC toolstack maintainers) On 25/05/2017 19:58, Feng Kan wrote: Hi All: Hello, This is not specifically against the XEN 4.9. I am using 4.12rc2 kernel on arm64 platform.

Re: [Xen-devel] [PATCH v2 1/2] doc, xen: document hypervisor sysfs nodes for xen

On 26/05/17 13:56, Juergen Gross wrote: > Today only a few sysfs nodes under /sys/hypervisor/ are documented > for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. > > Add the remaining Xen sysfs nodes under /sys/hypervisor/ in a new > file Documentation/ABI/stable/sysfs-hypervisor-xen and

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

On 05/26/17 17:29, Jan Beulich wrote: On 25.05.17 at 11:40, wrote: >> I've noticed that, with pages marked NX and vm_event emulation, we can >> end up emulating an ud2, for which hvm_emulate_one() returns >> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event(). > >

Re: [Xen-devel] [For Xen-4.10 PATCH v2 3/3] Avoid excess icache flushes in populate_physmap() before domain has been created

>>> On 26.05.17 at 13:14, wrote: > populate_physmap() calls alloc_heap_pages() per requested > extent. alloc_heap_pages() invalidates the entire icache per > extent. During domain creation, the icache invalidations can be deffered > until all the extents have been allocated

[Xen-devel] [ovmf test] 109761: all pass - PUSHED

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

[Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

Having a fixed version string in the seabios binary is cumbersome: - it is required to write something to '.version' in the toplevel directory of seabios-dir-remove. - it is required to pass EXTRAVERSION= to make. The latter is impossible without this change. For some reason an 'export

[Xen-devel] [xen-4.6-testing baseline-only test] 71335: regressions - FAIL

This run is configured for baseline tests only. flight 71335 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71335/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-520

[Xen-devel] [linux-4.9 test] 109749: regressions - FAIL

flight 109749 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109749/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358

Re: [Xen-devel] Commit moratorium for branching Xen 4.9

Hi Jan, On 26/05/17 07:02, Jan Beulich wrote: On 25.05.17 at 20:00, wrote: On 05/25/2017 01:46 PM, Julien Grall wrote: On 25/05/17 18:08, Boris Ostrovsky wrote: Is this: https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html being deferred

[Xen-devel] [For Xen-4.10 PATCH v2 3/3] Avoid excess icache flushes in populate_physmap() before domain has been created

populate_physmap() calls alloc_heap_pages() per requested extent. alloc_heap_pages() invalidates the entire icache per extent. During domain creation, the icache invalidations can be deffered until all the extents have been allocated as there is no risk of executing stale instructions from the

[Xen-devel] [For Xen-4.10 PATCH v2 1/3] Allow control of icache invalidations when calling flush_page_to_ram()

flush_page_to_ram() unconditionally drops the icache. In certain situations this leads to execessive icache flushes when flush_page_to_ram() ends up being repeatedly called in a loop. Introduce a parameter to allow callers of flush_page_to_ram() to take responsibility of synchronising the icache.

[Xen-devel] [For Xen-4.10 PATCH v2 2/3] arm: p2m: Prevent redundant icache flushes

When toolstack requests flushing the caches, flush_page_to_ram() is called for each page of the requested domain. This needs to unnecessary icache invalidation operations. Let's take the responsibility of performing icache operations and use the recently introduced flag to prevent redundant

[Xen-devel] [For Xen-4.10 PATCH v2 0/3] Reduce unnecessary icache maintenance operations

Hi, This series improves the number of icache flushes performed when allocating memory to a domain. This series was previously posted at [0] and [1]. Changes v1 -> v2: * Updated tags * Added a comment for icache_invalidate() definition for x86 to explain why it is empty. RFC -> v1: * Fixed

Re: [Xen-devel] [PATCH v4] x86/vpmu: add cpu hot unplug notifier for vpmu

On 05/26/2017 10:05 AM, Jan Beulich wrote: On 22.05.17 at 22:45, wrote: >> Currently, Hot unplug a physical CPU with vpmu enabled may cause >> system hang due to send a remote call to an offlined pCPU. This >> patch add a cpu hot unplug notifer to save vpmu context

Re: [Xen-devel] [PATCH 03/12 v3] xen/arm: vpl011: Add pl011 uart emulation in Xen

Hi Julien, Thanks for your comments. > > >> +static bool vpl011_reg32_check_access(int size) > > > Please pass hsr_dabt in parameter rather than the size directly. Which BTW > should have really be unsigned int. > ok. >> +{ >> +return (size == DABT_DOUBLE_WORD)? false : true; > > > This

Re: [Xen-devel] [PATCH v2 2/2] xen: add sysfs node for guest type

On 05/26/2017 08:56 AM, Juergen Gross wrote: > Currently there is no reliable user interface inside a Xen guest to > determine its type (e.g. HVM, PV or PVH). Instead of letting user mode > try to determine this by various rather hacky mechanisms (parsing of > boot messages before they are gone,

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

>>> On 25.05.17 at 11:40, wrote: > I've noticed that, with pages marked NX and vm_event emulation, we can > end up emulating an ud2, for which hvm_emulate_one() returns > X86EMUL_EXCEPTION in hvm_emulate_one_vm_event(). Could you explain what would lead to emulation of

[Xen-devel] [OSSTEST PATCH] arm64, armhf: Use dtuart for console by default

We don't want to have to set a host property for each ARM host. Julien writes: This command line should always work for arm64. If the device-tree does not provide the property then it is a bug. We want the command line to be as agnostic as possible from the platform. Reported-by: Julien

[Xen-devel] [PATCH v2 2/2] xen: add sysfs node for guest type

Currently there is no reliable user interface inside a Xen guest to determine its type (e.g. HVM, PV or PVH). Instead of letting user mode try to determine this by various rather hacky mechanisms (parsing of boot messages before they are gone, trying to make use of known subtle differences in

[Xen-devel] [PATCH v2 0/2] xen: add xen sysfs node

In order to be able to determine the Xen guest type from within the guest as a user there is currently no stable interface available. Add a sysfs node for that purpose as the guest type information is available for the kernel. While doing this document all the other Xen related sysfs nodes.

[Xen-devel] [PATCH v2 1/2] doc, xen: document hypervisor sysfs nodes for xen

Today only a few sysfs nodes under /sys/hypervisor/ are documented for Xen in Documentation/ABI/testing/sysfs-hypervisor-pmu. Add the remaining Xen sysfs nodes under /sys/hypervisor/ in a new file Documentation/ABI/stable/sysfs-hypervisor-xen and add the Xen specific sysfs docs to the MAINTAINERS

[Xen-devel] [for-4.9] Re: HVM guest performance regression

Juergen Gross writes ("HVM guest performance regression"): > Looking for the reason of a performance regression of HVM guests under > Xen 4.7 against 4.5 I found the reason to be commit > c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove freemem_slack") > in Xen 4.6. > > The problem

Re: [Xen-devel] HVM guest performance regression

On 26/05/17 19:04, Dario Faggioli wrote: > On Fri, 2017-05-26 at 18:14 +0200, Juergen Gross wrote: >> Looking for the reason of a performance regression of HVM guests >> under >> Xen 4.7 against 4.5 I found the reason to be commit >> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove >>

Re: [Xen-devel] [PATCH v2 06/18] xen/pvcalls: handle commands from the frontend

On 05/19/2017 07:22 PM, Stefano Stabellini wrote: > + > static void pvcalls_back_work(struct work_struct *work) > { > + struct pvcalls_back_priv *priv = container_of(work, > + struct pvcalls_back_priv, register_work); > + int notify, notify_all = 0, more = 1; > + struct

[Xen-devel] [PATCH 1/2] Revert "x86/hvm: disable pkeys for guests in non-paging mode"

This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53. When determining Access Rights, Protection Keys only take effect when CR4.PKE it set, and 4-level paging is active. All other circumstances (notibly, 32bit PAE paging) skip the Protection Key control mechanism. Therefore, we do not

[Xen-devel] [PATCH RFC for-4.9 0/2] x86/pagewalk: Further bugfixes to pagetable walking

These bugfixes finally allow my comprehensive XTF test (following several bugfixes, and the added feature of the 0-level pagetable tests) to complete successfully on a Skylake Server system, with PKU. I know this is getting very tight to the line on 4.9, but it would be nice to get these fixes

Re: [Xen-devel] HVM guest performance regression

On Fri, 2017-05-26 at 18:14 +0200, Juergen Gross wrote: > Looking for the reason of a performance regression of HVM guests > under > Xen 4.7 against 4.5 I found the reason to be commit > c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove > freemem_slack") > in Xen 4.6. > > The problem

[Xen-devel] [PATCH v10 02/32] ARM: GICv3: setup number of LPI bits for a GICv3 guest

The host supports a certain number of LPI identifiers, as stored in the GICD_TYPER register. Store this number from the hardware register in vgic_v3_hw to allow injecting the very same number into a guest (Dom0). DomUs get the legacy number of 10 bits here, since for now it only sees SPIs, so it

[Xen-devel] [PATCH v10 07/32] ARM: GICv3: introduce separate pending_irq structs for LPIs

For the same reason that allocating a struct irq_desc for each possible LPI is not an option, having a struct pending_irq for each LPI is also not feasible. We only care about mapped LPIs, so we can get away with having struct pending_irq's only for them. Maintain a radix tree per domain where we

[Xen-devel] [PATCH v10 05/32] ARM: vGIC: introduce gic_remove_irq()

To avoid code duplication in a later patch, introduce a generic function to remove a virtual IRQ from the VGIC. Call that function instead of the open-coded version in vgic_migrate_irq(). Signed-off-by: Andre Przywara --- xen/arch/arm/gic.c| 9 +

[Xen-devel] [PATCH v10 09/32] ARM: vGIC: cache virtual LPI priority in struct pending_irq

We enhance struct pending_irq to cache the priority information for LPIs. Reading the information from there is faster than accessing the property table from guest memory. Also it use some padding area in the struct, so does not require more memory. This introduces the function to retrieve the LPI

[Xen-devel] [PATCH v10 08/32] ARM: GIC: export and extend vgic_init_pending_irq()

For LPIs we later want to dynamically allocate struct pending_irqs. So beside needing to initialize the struct from there we also need to clean it up and re-initialize it later on. Export vgic_init_pending_irq() and extend it to be reusable. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v10 01/32] ARM: vGIC: avoid rank lock when reading priority

When reading the priority value of a virtual interrupt, we were taking the respective rank lock so far. However for forwarded interrupts (Dom0 only so far) this may lead to a deadlock with the following call chain: - MMIO access to change the IRQ affinity, calling the ITARGETSR handler - this

[Xen-devel] [PATCH v10 10/32] ARM: vGIC: add LPI VCPU ID to struct pending_irq

The target CPU for an LPI is encoded in the interrupt translation table entry, so can't be easily derived from just an LPI number (short of walking *all* tables and find the matching LPI). To avoid this in case we need to know the VCPU (for the INVALL command, for instance), put the VCPU ID in the

[Xen-devel] [PATCH v10 06/32] ARM: GIC: Add checks for NULL pointer pending_irq's

For LPIs the struct pending_irq's are dynamically allocated and the pointers will be stored in a radix tree. Since an LPI can be "unmapped" at any time, teach the VGIC how to deal with irq_to_pending() returning a NULL pointer. We just do nothing in this case or clean up the LR if the virtual LPI

[Xen-devel] [PATCH v10 04/32] ARM: vGIC: rework gic_remove_from_queues()

The function name gic_remove_from_queues() was a bit of a misnomer, since it just removes an IRQ from the pending queue, not both queues. Rename the function to make this more clear, also give it a pointer to a struct pending_irq directly and rely on the VGIC VCPU lock to be already taken, so this

[Xen-devel] [PATCH v10 03/32] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

So far irq_to_pending() is just a convenience function to lookup statically allocated arrays. This will change with LPIs, which are more dynamic, so the memory for their struct pending_irq might go away. The proper answer to the issue of preventing stale pointers is ref-counting, which requires

[Xen-devel] [xen-4.7-testing baseline-only test] 71380: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71380 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71380/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 11

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

>>> On 26.05.17 at 16:37, wrote: > On 05/26/17 17:29, Jan Beulich wrote: > On 25.05.17 at 11:40, wrote: >>> I've noticed that, with pages marked NX and vm_event emulation, we can >>> end up emulating an ud2, for which hvm_emulate_one()

Re: [Xen-devel] [PATCH v2 07/18] xen/pvcalls: implement socket command

> static int pvcalls_back_socket(struct xenbus_device *dev, > struct xen_pvcalls_request *req) > { > - return 0; > + struct pvcalls_back_priv *priv; > + int ret; > + struct xen_pvcalls_response *rsp; > + > + priv = dev_get_drvdata(>dev); > + > + if

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

On 26/05/17 18:19, Ian Jackson wrote: > Juergen Gross writes ("HVM guest performance regression"): >> Looking for the reason of a performance regression of HVM guests under >> Xen 4.7 against 4.5 I found the reason to be commit >> c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove

Re: [Xen-devel] [PATCH v3 8/9] vpci/msi: add MSI handlers

>>> On 27.04.17 at 16:35, wrote: > 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 >

[Xen-devel] [RFC] ARM PCI Passthrough design document

Hi all, The document below is an RFC version of a design proposal for PCI Passthrough in Xen on ARM. It aims to describe from an high level perspective the interaction with the different subsystems and how guest will be able to discover and access PCI. Currently on ARM, Xen does not have any

[Xen-devel] Exposing MFN to Host (Dom 0)

Hi, A few months ago I extended a prototyping hypervisor called Bareflank to include support for Intel Processor Trace (PT) and now I'm trying to implement similar functionality in Xen for research. My goal is to leverage the existing interfaces as much as possible to minimize the number of

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

On 26/05/17 15:29, Jan Beulich wrote: On 25.05.17 at 11:40, wrote: >> I've noticed that, with pages marked NX and vm_event emulation, we can >> end up emulating an ud2, for which hvm_emulate_one() returns >> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event(). > Could

Re: [Xen-devel] [PATCH v2 05/18] xen/pvcalls: connect to a frontend

On 05/19/2017 07:22 PM, Stefano Stabellini wrote: > Introduce a per-frontend data structure named pvcalls_back_priv. It > contains pointers to the command ring, its event channel, a list of > active sockets and a tree of passive sockets (passing sockets need to be > looked up from the id on

[Xen-devel] HVM guest performance regression

Looking for the reason of a performance regression of HVM guests under Xen 4.7 against 4.5 I found the reason to be commit c26f92b8fce3c9df17f7ef035b54d97cbe931c7a ("libxl: remove freemem_slack") in Xen 4.6. The problem occurred when dom0 had to be ballooned down when starting the guest. The

[Xen-devel] [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches

Despite the claim in the comment (which was based partly on the code already being like that, and mistaken reasoning because of Xen leaking NX into guest context), reality differs. Use of the SMAP feature without NX, or in a 2-level guest, demonstrate an observable difference between reads and

[Xen-devel] [linux-linus test] 109758: regressions - FAIL

flight 109758 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/109758/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 109656 Tests which are

Re: [Xen-devel] [PATCH v9 12/28] ARM: vGIC: advertise LPI support

Hi, On 26/05/17 11:19, Julien Grall wrote: > Hi Stefano, > > On 25/05/17 22:05, Stefano Stabellini wrote: >> On Thu, 25 May 2017, Julien Grall wrote: >>> Hi Stefano, >>> >>> On 25/05/2017 19:49, Stefano Stabellini wrote: On Thu, 25 May 2017, Andre Przywara wrote: > Hi, > > On

[Xen-devel] [PATCH v10 11/32] ARM: GICv3: forward pending LPIs to guests

Upon receiving an LPI on the host, we need to find the right VCPU and virtual IRQ number to get this IRQ injected. Iterate our two-level LPI table to find the domain ID and the virtual LPI number quickly when the host takes an LPI. We then look up the right VCPU in the struct pending_irq. We use

[Xen-devel] [PATCH v10 00/32] arm64: Dom0 ITS emulation

Hi, yet another rework, addressing comments on v9. The same restriction as for v9 still apply: the locking is considered somewhat insufficient and will be fixed by an upcoming rework. Most of the fixes are smaller changes as requested by the reviewers. Some preparatory patches have been moved

[Xen-devel] [PATCH v10 20/32] ARM: vITS: handle INT command

The INT command sets a given LPI identified by a DeviceID/EventID pair as pending and thus triggers it to be injected. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 21 + 1 file changed, 21 insertions(+) diff --git

[Xen-devel] [PATCH v10 15/32] ARM: vGICv3: re-use vgic_reg64_check_access

vgic_reg64_check_access() checks for a valid access width of a 64-bit MMIO register, which is useful beyond the current GICv3 emulation only. Move this function to the vgic-emul.h to be easily reusable. Signed-off-by: Andre Przywara Acked-by: Julien Grall

[Xen-devel] [PATCH v10 19/32] ARM: vITS: provide access to struct pending_irq

For each device we allocate one struct pending_irq for each virtual event (MSI). Provide a helper function which returns the pointer to the appropriate struct, to be able to find the right struct when given a virtual deviceID/eventID pair. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v10 13/32] ARM: vGICv3: handle virtual LPI pending and property tables

Allow a guest to provide the address and size for the memory regions it has reserved for the GICv3 pending and property tables. We sanitise the various fields of the respective redistributor registers. The MMIO read and write accesses are protected by locks, to avoid any changing of the property

[Xen-devel] [PATCH v10 18/32] ARM: vITS: introduce translation table walks

The ITS stores the target (v)CPU and the (virtual) LPI number in tables. Introduce functions to walk those tables and translate an device ID - event ID pair into a pair of virtual LPI and vCPU. We map those tables on demand - which is cheap on arm64 - and copy the respective entries before using

[Xen-devel] [PATCH v10 16/32] ARM: vGIC: advertise LPI support

To let a guest know about the availability of virtual LPIs, set the respective bits in the virtual GIC registers and let a guest control the LPI enable bit. Only report the LPI capability if the host has initialized at least one ITS. For Dom0 we report the same number of interrupts identifiers as

[Xen-devel] [PATCH v10 31/32] ARM: vITS: create and initialize virtual ITSes for Dom0

For each hardware ITS create and initialize a virtual ITS for Dom0. We use the same memory mapped address to keep the doorbell working. This introduces a function to initialize a virtual ITS. We maintain a list of virtual ITSes, at the moment for the only purpose of later being able to free them

[Xen-devel] [PATCH v10 25/32] ARM: vITS: handle MAPTI/MAPI command

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU pair and actually instantiates LPI interrupts. MAPI is just a variant of this comment, where the LPI ID is the same as the event ID. We connect the already allocated host LPI to this virtual LPI, so that any triggering LPI on the

[Xen-devel] [PATCH v10 29/32] ARM: vITS: handle INVALL command

The INVALL command instructs an ITS to invalidate the configuration data for all LPIs associated with a given redistributor (read: VCPU). This is nasty to emulate exactly with our architecture, so we just iterate over all mapped LPIs and filter for those from that particular VCPU. Signed-off-by:

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

flight 109764 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/109764/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail REGR. vs. 109690 Tests which did

Re: [Xen-devel] [PATCH v2 11/18] xen/pvcalls: implement accept command

> static void __pvcalls_back_accept(struct work_struct *work) > { > + struct sockpass_mapping *mappass = container_of( > + work, struct sockpass_mapping, register_work); > + struct sock_mapping *map; > + struct pvcalls_ioworker *iow; > + struct pvcalls_back_priv

Re: [Xen-devel] Exposing MFN to Host (Dom 0)

On 26/05/17 15:40, Carter Yagemann wrote: > Hi, > > A few months ago I extended a prototyping hypervisor called Bareflank to > include support for Intel Processor Trace (PT) and now I'm trying to > implement similar functionality in Xen for research. My goal is to > leverage the existing

[Xen-devel] [PATCH v10 28/32] ARM: vITS: handle INV command

The INV command instructs the ITS to update the configuration data for a given LPI by re-reading its entry from the property table. We don't need to care so much about the priority value, but enabling or disabling an LPI has some effect: We remove or push virtual LPIs to their VCPUs, also check

[Xen-devel] [PATCH v10 32/32] ARM: vITS: create ITS subnodes for Dom0 DT

Dom0 expects all ITSes in the system to be propagated to be able to use MSIs. Create Dom0 DT nodes for each hardware ITS, keeping the register frame address the same, as the doorbell address that the Dom0 drivers program into the BARs has to match the hardware. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v10 24/32] ARM: GICv3: handle unmapped LPIs

When LPIs get unmapped by a guest, they might still be in some LR of some VCPU. Nevertheless we remove the corresponding pending_irq (possibly freeing it), and detect this case (irq_to_pending() returns NULL) when the LR gets cleaned up later. However a *new* LPI may get mapped with the same

[Xen-devel] [PATCH v10 21/32] ARM: vITS: handle MAPC command

The MAPC command associates a given collection ID with a given redistributor, thus mapping collections to VCPUs. We just store the vcpu_id in the collection table for that. Signed-off-by: Andre Przywara Acked-by: Julien Grall ---

[Xen-devel] [PATCH v10 17/32] ARM: vITS: add command handling stub and MMIO emulation

Emulate the memory mapped ITS registers and provide a stub to introduce the ITS command handling framework (but without actually emulating any commands at this time). This fixes a misnomer in our virtual ITS structure, where the spec is confusingly using ID_bits in GITS_TYPER to denote the number

[Xen-devel] [libvirt test] 109759: regressions - FAIL

flight 109759 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/109759/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt 5 xen-install fail REGR. vs. 109736 Tests which did not

[Xen-devel] [PATCH v10 14/32] ARM: introduce vgic_access_guest_memory()

From: Vijaya Kumar K This function allows to copy a chunk of data from and to guest physical memory. It looks up the associated page from the guest's p2m tree and maps this page temporarily for the time of the access. This function was originally written by

[Xen-devel] [PATCH v10 22/32] ARM: vITS: handle CLEAR command

This introduces the ITS command handler for the CLEAR command, which clears the pending state of an LPI. This removes a not-yet injected, but already queued IRQ from a VCPU. As read_itte() is now eventually used, we add the static keyword. Signed-off-by: Andre Przywara

[Xen-devel] [PATCH v10 23/32] ARM: vITS: handle MAPD command

The MAPD command maps a device by associating a memory region for storing ITEs with a certain device ID. Since it features a valid bit, MAPD also covers the "unmap" functionality, which we also cover here. We store the given guest physical address in the device table, and, if this command comes

[Xen-devel] [PATCH v10 26/32] ARM: vITS: handle MOVI command

The MOVI command moves the interrupt affinity from one redistributor (read: VCPU) to another. For now migration of "live" LPIs is not yet implemented, but we store the changed affinity in our virtual ITTE and the pending_irq. Signed-off-by: Andre Przywara ---

[Xen-devel] [PATCH v10 12/32] ARM: GICv3: enable ITS and LPIs on the host

Now that the host part of the ITS code is in place, we can enable the ITS and also LPIs on each redistributor to get the show rolling. At this point there would be no LPIs mapped, as guests don't know about the ITS yet. Signed-off-by: Andre Przywara Acked-by: Stefano

[Xen-devel] [PATCH v10 27/32] ARM: vITS: handle DISCARD command

The DISCARD command drops the connection between a DeviceID/EventID and an LPI/collection pair. We mark the respective structure entries as not allocated and make sure that any queued IRQs are removed. Signed-off-by: Andre Przywara --- xen/arch/arm/vgic-v3-its.c | 27

Re: [Xen-devel] [PATCH v2 07/18] xen/pvcalls: implement socket command

On 05/19/2017 07:22 PM, Stefano Stabellini wrote: > Just reply with success to the other end for now. Delay the allocation > of the actual socket to bind and/or connect. > > Signed-off-by: Stefano Stabellini > CC: boris.ostrov...@oracle.com > CC: jgr...@suse.com > --- >

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hello Stefano, >> > The problem with stubdoms is latency and scheduling. It is not >> > deterministic. We could easily improve the null scheduler to introduce >> > some sort of non-preemptive scheduling of stubdoms on the same pcpus of >> > the guest vcpus. It would still require manually pinning

Re: [Xen-devel] Notes on stubdoms and latency on ARM

On 26 May 2017 at 12:43, Volodymyr Babchuk wrote: > Hi Dario, > Oops, sorry, George. There was two emails in a row: yours one and Dario's one. And I overlooked to whom I'm answering. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babc...@gmail.com

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hello Dario, >> I'm not very familiar with XEN schedulers. > Feel free to ask anything. :-) I'm so unfamiliar, so even don't know what to ask :) But thank you. Surely I'll have questions. >> Looks like null scheduler >> is good for hard RT, but isn't fine for a generic consumer system. >> > The

[Xen-devel] [PATCH v10 30/32] ARM: vITS: increase mmio_count for each ITS

Increase the count of MMIO regions needed by one for each ITS Dom0 has to emulate. We emulate the ITSes 1:1 from the hardware, so the number is the number of host ITSes. Signed-off-by: Andre Przywara Acked-by: Julien Grall ---

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

On Fri, 26 May 2017, Juergen Gross wrote: > On 26/05/17 18:19, Ian Jackson wrote: > > Juergen Gross writes ("HVM guest performance regression"): > >> Looking for the reason of a performance regression of HVM guests under > >> Xen 4.7 against 4.5 I found the reason to be commit > >>

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hi Dario, >>> Explanation of what EL0 apps are. What should be their interface with >>> Xen? Could the interface be the regular hypercall interface? In that >>> case, what's the benefit compared to stubdoms? >> I imagined this as separate syscall interface (with finer policy >> rules). But this

[Xen-devel] [linux-3.18 baseline-only test] 71440: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71440 linux-3.18 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71440/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16

Re: [Xen-devel] Notes on stubdoms and latency on ARM

On Fri, 2017-05-26 at 13:09 -0700, Volodymyr Babchuk wrote: > Hello Dario, > Hi, > > Feel free to ask anything. :-) > > I'm so unfamiliar, so even don't know what to ask :) But thank you. > Surely I'll have questions. > Sure. As soon as you have one, go ahead with it. > > The null scheduler is

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

flight 109766 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/109766/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 7 host-ping-check-xen fail REGR. vs. 109758

[Xen-devel] [PATCH 2/2] xen-access: write_ctrlreg_c4 test

Add test for write_ctrlreg event handling. Signed-off-by: Petre Pircalabu --- tools/tests/xen-access/xen-access.c | 43 - 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/tools/tests/xen-access/xen-access.c

[Xen-devel] write_ctrlreg event masking

Hello, This patchset enables masking the reception of write_ctrlreg events depending on the value of certain bits in that register. The most representative example is filtering out events when the CR4.PGE bit is being flipped (global TLB flushes) Best regards, Petre

[Xen-devel] [PATCH 1/2] x86/monitor: add masking support for write_ctrlreg events

Add support for filtering out the write_ctrlreg monitor events if they are generated only by changing certains bits. A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg function in order to mask the event generation if the changed bits are set. Signed-off-by: Petre Pircalabu

[Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

Olaf Hering writes ("[PATCH] tools/firmware: pass EXTRAVERSION to seabios build"): > Having a fixed version string in the seabios binary is cumbersome: > - it is required to write something to '.version' in the toplevel >directory of seabios-dir-remove. > - it is required to pass

Re: [Xen-devel] [PATCH v4] x86/vpmu: add cpu hot unplug notifier for vpmu

>>> On 22.05.17 at 22:45, wrote: > Currently, Hot unplug a physical CPU with vpmu enabled may cause > system hang due to send a remote call to an offlined pCPU. This > patch add a cpu hot unplug notifer to save vpmu context before > cpu offline. > > Consider one scenario,

Re: [Xen-devel] Question about QEMU as ide device emulator

Question has been answered. Thanks. On Thu, May 25, 2017 at 6:35 PM, Bruno Alvisio wrote: > Hello all, > > Summary > > I am using XEN hypervisor to run a HVM with a QEMU backed disk. After I > start the HVM I use QMP "query-block" command to see the devices of the VM. >

[Xen-devel] [ovmf baseline-only test] 71441: tolerable FAIL

This run is configured for baseline tests only. flight 71441 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71441/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

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

flight 109747 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/109747/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 109707

Re: [Xen-devel] [PATCH v9 19/28] ARM: vITS: handle MAPD command

Hi, On 25/05/17 21:44, Stefano Stabellini wrote: > On Thu, 25 May 2017, Julien Grall wrote: >> On 25/05/2017 19:55, Stefano Stabellini wrote: >>> On Wed, 24 May 2017, Andre Przywara wrote: Hi, On 24/05/17 10:56, Julien Grall wrote: > Hi Andre, > > On 05/24/2017 10:10

Re: [Xen-devel] [PATCH v4 for-4.9] x86/vpmu: add cpu hot unplug notifier for vpmu

>>> On 26.05.17 at 07:20, wrote: > Hi Jan, > If there have anything need to change in this patch? I didn't get to look at v4 yet - too busy with other stuff. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] Commit moratorium for branching Xen 4.9

>>> On 25.05.17 at 20:00, wrote: > On 05/25/2017 01:46 PM, Julien Grall wrote: >> On 25/05/17 18:08, Boris Ostrovsky wrote: >>> Is this: >>> >>> https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02340.html >>> >>> >>> being deferred to the next RC (if we

Re: [Xen-devel] [PATCH] x86/vmx: Fix vmentry failure because of invalid LER on Broadwell

Hi Ross, On Thu, 2017-05-25 at 13:15 +0100, Ross Lagerwall wrote: > Occasionally, the top three bits of MSR_IA32_LASTINTTOIP > (MSR_LER_TO_LIP) may be incorrect, as though the MSR is using the > LBR_FORMAT_EIP_FLAGS_TSX format. The MSR should contain an offset into > the current code segment

  1   2   >