[Xen-devel] [xen-4.7-testing test] 110430: tolerable FAIL - PUSHED

flight 110430 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/110430/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 109620 test-xtf-amd64-amd64-1 45

[Xen-devel] [qemu-mainline test] 110428: regressions - FAIL

flight 110428 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/110428/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 5 xen-install fail REGR. vs. 109975 Tests which did

[Xen-devel] [linux-linus test] 110427: tolerable FAIL - PUSHED

flight 110427 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/110427/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 110380 test-armhf-armhf-xl-rtds

Re: [Xen-devel] [RFC PATCH] docs: add README.atomic

On Wed, 14 Jun 2017, Jan Beulich wrote: > >>> Stefano Stabellini 06/14/17 8:45 PM >>> > >On Wed, 14 Jun 2017, Jan Beulich wrote: > >> > +What ACCESS_ONCE does *not* guarantee though is this access is done in a > >> > +single instruction, so complex or non-native or

[Xen-devel] [seabios baseline-only test] 71564: tolerable FAIL

This run is configured for baseline tests only. flight 71564 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71564/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop

Re: [Xen-devel] [RFC PATCH 3/4] xl: introduce facility to run function with per-domain lock held

On Wed, Jun 14, 2017 at 06:19:20PM +0100, Wei Liu wrote: > Signed-off-by: Wei Liu > --- > tools/xl/xl.h | 1 + > tools/xl/xl_utils.c | 19 +++ > tools/xl/xl_utils.h | 3 +++ > 3 files changed, 23 insertions(+) > > diff --git a/tools/xl/xl.h

[Xen-devel] [libvirt test] 110425: tolerable all pass - PUSHED

flight 110425 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/110425/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 110397 test-armhf-armhf-libvirt-raw 12

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

flight 110423 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/110423/ 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 Tests which are

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

On Mon, 12 Jun 2017, Boris Ostrovsky wrote: > > + > > static void pvcalls_back_work(struct work_struct *work) > > { > > + struct pvcalls_fedata *priv = container_of(work, > > + struct pvcalls_fedata, register_work); > > + int notify, notify_all = 0, more = 1; > > + struct

[Xen-devel] [xen-unstable-smoke test] 110455: tolerable trouble: broken/pass - PUSHED

flight 110455 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/110455/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

Re: [Xen-devel] [PATCH] xen/include/asm-x86/hvm/svm/vmcb.h: Correction in comments.

On 06/14/2017 03:19 PM, Dushyant Behl wrote: > The VMEXIT codes listed from EXCEPTION_PF to EXCEPTION_XF had comments > describe the exitcodes slightly shifted than the expected value. > The expected exitcode value for page-fault is 78 which should be 0x4E > and so on till exception XF. > >

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

On Wed, 14 Jun 2017, Juergen Gross wrote: > On 14/06/17 02:47, Stefano Stabellini wrote: > > On Tue, 13 Jun 2017, Juergen Gross wrote: > >> On 02/06/17 21:31, Stefano Stabellini wrote: > >>> Implement the accept command by calling inet_accept. To avoid blocking > >>> in the kernel, call

Re: [Xen-devel] Incorrect Comment in xen/include/asm-x86/hvm/svm/vmcb.h

On Wed, Jun 14, 2017 at 2:19 PM, Jan Beulich wrote: On 13.06.17 at 17:49, wrote: >> Hi Everyone, >> >> I was looking at the SVM setup code in Xen when I noticed that some >> comments describing the VMEXIT codes look wrong. >> The processor

[Xen-devel] [PATCH] xen/include/asm-x86/hvm/svm/vmcb.h: Correction in comments.

The VMEXIT codes listed from EXCEPTION_PF to EXCEPTION_XF had comments describe the exitcodes slightly shifted than the expected value. The expected exitcode value for page-fault is 78 which should be 0x4E and so on till exception XF. Signed-off-by: Dushyant Behl

Re: [Xen-devel] [PATCH v3 14/18] xen/pvcalls: disconnect and module_exit

On Wed, 14 Jun 2017, Boris Ostrovsky wrote: > >>> static int backend_disconnect(struct xenbus_device *dev) > >>> { > >>> + struct pvcalls_fedata *priv; > >>> + struct sock_mapping *map, *n; > >>> + struct sockpass_mapping *mappass; > >>> + struct radix_tree_iter iter; > >>> + void **slot; > >>>

Re: [Xen-devel] [PATCH 2/2] xen/livepatch: Don't crash on encountering STN_UNDEF relocations

On Wed, Jun 14, 2017 at 07:33:57PM +0100, Andrew Cooper wrote: > On 14/06/17 15:18, Konrad Rzeszutek Wilk wrote: > > On Wed, Jun 14, 2017 at 04:24:00AM -0600, Jan Beulich wrote: > > On 14.06.17 at 12:13, wrote: > >>> On 14/06/17 11:11, Jan Beulich wrote: > >>>

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

On Wed, 14 Jun 2017, Boris Ostrovsky wrote: > + Stefano for ARM. > > On 06/12/2017 10:21 AM, 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

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

> Hmm, okay. Are you fine with the attached patch? Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

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

On 14/06/17 19:43, Boris Ostrovsky wrote: > >> --- a/Documentation/ABI/testing/sysfs-hypervisor-pmu >> +++ b/Documentation/ABI/testing/sysfs-hypervisor-xen >> @@ -1,8 +1,19 @@ >> +What: /sys/hypervisor/guest_type >> +Date: May 2017 >> +KernelVersion: 4.13 >>

Re: [Xen-devel] [RFC PATCH] docs: add README.atomic

>>> Stefano Stabellini 06/14/17 8:45 PM >>> >On Wed, 14 Jun 2017, Jan Beulich wrote: >> > +What ACCESS_ONCE does *not* guarantee though is this access is done in a >> > +single instruction, so complex or non-native or unaligned data types are >> > +not guaranteed to be

Re: [Xen-devel] [PATCH 2/2] xen/livepatch: Don't crash on encountering STN_UNDEF relocations

>>> Andrew Cooper 06/14/17 8:34 PM >>> >Well - I've got a livepatch with such a relocation. It is probably a >livepatch build tools issue, but the question is whether Xen should ever >accept such a livepatch or not (irrespective of whether this exact >relocation is

Re: [Xen-devel] [RFC PATCH] docs: add README.atomic

On Wed, 14 Jun 2017, Jan Beulich wrote: > > +What ACCESS_ONCE does *not* guarantee though is this access is done in a > > +single instruction, so complex or non-native or unaligned data types are > > +not guaranteed to be atomic. If for instance counter would be a 64-bit > > value > > +on a

Re: [Xen-devel] [PATCH v12 00/34] arm64: Dom0 ITS emulation

On Wed, 14 Jun 2017, Andre Przywara wrote: > Hi, > > hopefully the final version, with only nits from v11 addressed. > The same restriction as for the previous versions still apply: the locking > is considered somewhat insufficient and will be fixed by an upcoming rework. > > Patches 01/34 and

[Xen-devel] [seabios test] 110421: tolerable FAIL - PUSHED

flight 110421 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/110421/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 110383 test-amd64-i386-xl-qemuu-win7-amd64 16

Re: [Xen-devel] [PATCH 2/2] xen/livepatch: Don't crash on encountering STN_UNDEF relocations

On 14/06/17 15:18, Konrad Rzeszutek Wilk wrote: > On Wed, Jun 14, 2017 at 04:24:00AM -0600, Jan Beulich wrote: > On 14.06.17 at 12:13, wrote: >>> On 14/06/17 11:11, Jan Beulich wrote: >>> On 13.06.17 at 22:51, wrote: > ---

Re: [Xen-devel] [PATCH v11 01/34] ARM: vGIC: avoid rank lock when reading priority

Hi Stefano, On 06/14/2017 07:15 PM, Stefano Stabellini wrote: On Wed, 14 Jun 2017, Julien Grall wrote: In any case, all those macros does not prevent re-ordering at the processor level nor read/write atomicity if the variable is misaligned. My understanding is that the unwritten assumption

Re: [Xen-devel] [PATCH 1/2] xen/livepatch: Clean up arch relocation handling

On 14/06/17 15:02, Jan Beulich wrote: On 14.06.17 at 15:44, wrote: >> On Tue, Jun 13, 2017 at 09:51:35PM +0100, Andrew Cooper wrote: >>> --- a/xen/arch/arm/arm32/livepatch.c >>> +++ b/xen/arch/arm/arm32/livepatch.c >>> @@ -224,21 +224,21 @@ int

Re: [Xen-devel] [PATCH v12 25/34] ARM: vITS: handle MAPD command

On Wed, 14 Jun 2017, Andre Przywara wrote: > 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

Re: [Xen-devel] [PATCH v11 01/34] ARM: vGIC: avoid rank lock when reading priority

On Wed, 14 Jun 2017, Julien Grall wrote: > > > > > In any case, all those macros does not prevent re-ordering at the > > > > > processor > > > > > level nor read/write atomicity if the variable is misaligned. > > > > > > > > My understanding is that the unwritten assumption in Xen is that > > > >

Re: [Xen-devel] [PATCH v12 00/34] arm64: Dom0 ITS emulation

On 06/14/2017 05:51 PM, Andre Przywara wrote: Hi, Hi Andre, hopefully the final version, with only nits from v11 addressed. The same restriction as for the previous versions still apply: the locking is considered somewhat insufficient and will be fixed by an upcoming rework. I have

Re: [Xen-devel] [PATCH v12 25/34] ARM: vITS: handle MAPD command

Hi Andre, On 06/14/2017 05:52 PM, Andre Przywara wrote: 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

Re: [Xen-devel] [PATCH v12 07/34] ARM: vGIC: introduce gic_remove_irq_from_queues()

Hi Andre, On 06/14/2017 05:51 PM, Andre Przywara wrote: 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

Re: [Xen-devel] [PATCH v12 06/34] ARM: vGIC: move irq_to_pending() calls under the VGIC VCPU lock

Hi Andre, On 06/14/2017 05:51 PM, Andre Przywara wrote: 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

Re: [Xen-devel] [PATCH v12 05/34] ARM: vGIC: rework gic_remove_from_queues()

Hi Andre, On 06/14/2017 05:51 PM, Andre Przywara wrote: 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

Re: [Xen-devel] [PATCH v12 01/34] ARM: vGIC: avoid rank lock when reading priority

Hi Andre, On 06/14/2017 05:51 PM, Andre Przywara wrote: 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

Re: [Xen-devel] [PATCH v4 4/4] xen: add sysfs node for hypervisor build id

On 06/14/2017 01:23 PM, Juergen Gross wrote: > For support of Xen hypervisor live patching the hypervisor build id is > needed. Add a node /sys/hypervisor/properties/buildid containing the > information. > > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH v11 01/34] ARM: vGIC: avoid rank lock when reading priority

Hi Stefano, On 06/14/2017 06:32 PM, Stefano Stabellini wrote: On Wed, 14 Jun 2017, Julien Grall wrote: I don't understand your explanation. There are no PV protocols under xen/, they are implemented in other repositories. I grepped for ACCESS under xen/include/public, in case you referred to

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

> --- a/Documentation/ABI/testing/sysfs-hypervisor-pmu > +++ b/Documentation/ABI/testing/sysfs-hypervisor-xen > @@ -1,8 +1,19 @@ > +What:/sys/hypervisor/guest_type > +Date:May 2017 > +KernelVersion: 4.13 > +Contact: xen-de...@lists.xenproject.org >

Re: [Xen-devel] [PATCH v11 01/34] ARM: vGIC: avoid rank lock when reading priority

On Wed, 14 Jun 2017, Julien Grall wrote: > On 06/13/2017 11:19 PM, Stefano Stabellini wrote: > > On Tue, 13 Jun 2017, Julien Grall wrote: > > > On 12/06/2017 23:34, Stefano Stabellini wrote: > > > > On Mon, 12 Jun 2017, Julien Grall wrote: > > > > > Hi Andre, > > > > > > > > > > On 09/06/17

Re: [Xen-devel] [PATCH] xen: allocate page for shared info page from low memory

On 06/14/2017 01:11 PM, Juergen Gross wrote: > On 14/06/17 18:58, Boris Ostrovsky wrote: >> On 06/12/2017 07:53 AM, Juergen Gross wrote: >>> In a HVM guest the kernel allocates the page for mapping the shared >>> info structure via extend_brk() today. This will lead to a drop of >>> performance as

[Xen-devel] [PATCH v4 2/4] 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 v4 0/4] xen: add xen sysfs nodes

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

[Xen-devel] [PATCH v4 3/4] xen: sync include/xen/interface/version.h

Sync include/xen/interface/version.h with the Xen source. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky --- include/xen/interface/version.h | 15 +++ 1 file changed, 15 insertions(+) diff --git

[Xen-devel] [PATCH v4 4/4] xen: add sysfs node for hypervisor build id

For support of Xen hypervisor live patching the hypervisor build id is needed. Add a node /sys/hypervisor/properties/buildid containing the information. Signed-off-by: Juergen Gross --- V4: - send correct patch --- Documentation/ABI/testing/sysfs-hypervisor-xen | 11

[Xen-devel] [PATCH v4 1/4] 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

Re: [Xen-devel] tags in backport commits

On Wed, 14 Jun 2017, Jan Beulich wrote: > >>> On 13.06.17 at 19:41, wrote: > > On Tue, 13 Jun 2017, George Dunlap wrote: > >> On 13/06/17 08:28, Jan Beulich wrote: > >> > Furthermore - who would you mean to create these tags? In the > >> > end I think it should be the

[Xen-devel] [RFC PATCH 0/4] Per-domain locking in xl

It has always been the case that different xl processes can manipulate the same domain at the same time. This could be problematic. This series attempts to provide facility for xl to have a per-domain lock. This lock should be used whenever xl manipulates an existing domain. The last patch is an

[Xen-devel] [RFC PATCH 4/4] XXX a command to test the locking facility

Signed-off-by: Wei Liu --- tools/xl/xl.h | 2 ++ tools/xl/xl_cmdtable.c | 5 + tools/xl/xl_misc.c | 37 + 3 files changed, 44 insertions(+) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index 8d667ff444..9cb135baf2 100644

[Xen-devel] [RFC PATCH 2/4] xl: make lock functions work with arbitrary files and fds

Rename the existing lock to xl_global lock. Refactor the functions to take the filename and fd so that they can work with any filename and fd. No functional change. Signed-off-by: Wei Liu --- tools/xl/xl.c | 19 ++- tools/xl/xl.h | 3

[Xen-devel] [RFC PATCH 1/4] xl: move {acquire, release}_lock to xl_utils.c

Pure code motion, no functional change. Signed-off-by: Wei Liu --- tools/xl/xl_utils.c | 67 + tools/xl/xl_utils.h | 3 +++ tools/xl/xl_vmcontrol.c | 67 - 3 files

[Xen-devel] [RFC PATCH 3/4] xl: introduce facility to run function with per-domain lock held

Signed-off-by: Wei Liu --- tools/xl/xl.h | 1 + tools/xl/xl_utils.c | 19 +++ tools/xl/xl_utils.h | 3 +++ 3 files changed, 23 insertions(+) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index 93ec4d7e4c..8d667ff444 100644 --- a/tools/xl/xl.h +++

Re: [Xen-devel] [PATCH] xen: allocate page for shared info page from low memory

On 14/06/17 18:58, Boris Ostrovsky wrote: > On 06/12/2017 07:53 AM, Juergen Gross wrote: >> In a HVM guest the kernel allocates the page for mapping the shared >> info structure via extend_brk() today. This will lead to a drop of >> performance as the underlying EPT entry will have to be split up

Re: [Xen-devel] [PATCH] xen: allocate page for shared info page from low memory

On 06/12/2017 07:53 AM, Juergen Gross wrote: > In a HVM guest the kernel allocates the page for mapping the shared > info structure via extend_brk() today. This will lead to a drop of > performance as the underlying EPT entry will have to be split up into > 4kB entries as the single shared info

[Xen-devel] [PATCH v12 33/34] 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 v12 32/34] 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 ---

[Xen-devel] [PATCH] xen: idle_loop: either deal with tasklets or go idle

In fact, there exists two kind of tasklets: vCPU and softirq context tasklets. When we want to do vCPU context tasklet work, we force the idle vCPU (of a particular pCPU) into execution, and run it from there. This means there are two possible reasons for choosing to run the idle vCPU: 1) we want

[Xen-devel] [PATCH v12 25/34] 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 v12 28/34] 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 Acked-by: Julien

[Xen-devel] [PATCH v12 27/34] 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 v12 22/34] 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. As read_itte() is now eventually used, we add the static keyword. Signed-off-by: Andre Przywara Reviewed-by: Julien Grall ---

[Xen-devel] [PATCH v12 18/34] 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 there is at least one ITS emulated for that guest (which depends on the host having an ITS at the moment).

[Xen-devel] [PATCH v12 15/34] 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 v12 26/34] 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] xen: idle_loop: either deal with tasklets or go idle

Hi, following up on this: https://lists.xen.org/archives/html/xen-devel/2017-06/msg01260.html I did make a patch that moves do_tasklet() up a bit, within idle_loop(). While there, I did a bit more than that... let's see what you guys think. :-D I've verified that this builds on ARM too, but

[Xen-devel] [PATCH v12 29/34] 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 Acked-by: Julien Grall

[Xen-devel] [PATCH v12 31/34] 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] [PATCH v12 30/34] 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 v12 34/34] 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 v12 24/34] 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. Signed-off-by: Andre Przywara Acked-by: Julien Grall ---

[Xen-devel] [PATCH v12 14/34] 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 v12 21/34] 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 v12 23/34] 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 v12 20/34] 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 v12 19/34] 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] [PATCH v12 10/34] 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 v12 13/34] ARM: GIC: ITS: remove no longer needed VCPU ID in host LPI entry

To get easy access to the VCPU a forwarded LPI interrupt should be injected to, so far we stored the VCPU ID in the host LPI entry. However this creates a redundancy, since we keep the target VCPU in the struct pending_irq already, which we can easily look up given the domain and the virtual LPI

[Xen-devel] [PATCH v12 00/34] arm64: Dom0 ITS emulation

Hi, hopefully the final version, with only nits from v11 addressed. The same restriction as for the previous versions still apply: the locking is considered somewhat insufficient and will be fixed by an upcoming rework. Patches 01/34 and 02/34 should be applied for 4.9 still, since they fix

[Xen-devel] [PATCH v12 02/34] ARM: GICv3: enable ITS on the host

Even though the ITS emulation is not yet in place, the host ITS already gets initialized and Xen tries to map the host collections. However for commands to be processed we need to *enable* the ITS, which will be done in a later patch not yet merged. So those MAPC commands are not processed and run

[Xen-devel] [PATCH v12 17/34] 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 v12 06/34] 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] [PATCH v12 05/34] 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 v12 11/34] 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 v12 12/34] 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 v12 16/34] 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 v12 01/34] 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 v12 04/34] 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 v12 03/34] ARM: GICv3: enable LPIs on the host

Now that the host part of the ITS code is in place, we can enable the 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 Stabellini

[Xen-devel] [PATCH v12 09/34] 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 v12 08/34] 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 v12 07/34] ARM: vGIC: introduce gic_remove_irq_from_queues()

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 +

Re: [Xen-devel] [PATCH v11 10/34] ARM: GIC: export and extend vgic_init_pending_irq()

Hi Andre, On 06/14/2017 04:54 PM, Andre Przywara wrote: Hi, On 12/06/17 16:36, Julien Grall wrote: Hi Andre, On 09/06/17 18:41, Andre Przywara wrote: For LPIs we later want to dynamically allocate struct pending_irqs. So beside needing to initialize the struct from there we also need to

[Xen-devel] [xen-4.9-testing test] 110417: tolerable FAIL - PUSHED

flight 110417 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/110417/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 110374

Re: [Xen-devel] [PATCH v11 10/34] ARM: GIC: export and extend vgic_init_pending_irq()

Hi, On 12/06/17 16:36, Julien Grall wrote: > Hi Andre, > > On 09/06/17 18:41, Andre Przywara wrote: >> 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. >>

[Xen-devel] [xen-unstable-smoke test] 110440: tolerable trouble: broken/pass - PUSHED

flight 110440 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/110440/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

Re: [Xen-devel] [PATCH 2/2] arm: traps: handle PSCI calls inside `smccc.c`

On 06/14/2017 03:37 PM, Volodymyr Babchuk wrote: Hi Julien, Hi Volodymyr, On 14.06.17 17:21, Julien Grall wrote: PSCI is part of HVC/SMC interface, so it should be handled in appropriate place: `smccc.c`. This patch just moves PSCI handler calls from `traps.c` to `smccc.c`. PSCI is

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

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

Re: [Xen-devel] About the parameter list of tools/libxc/xc_domain.c:xc_domain_add_to_physmap()

I didn't saw your mail. Sorry. 2017-06-14 23:13 GMT+08:00 Zhongze Liu : > 2017-06-14 22:42 GMT+08:00 Wei Liu : >> On Wed, Jun 14, 2017 at 09:19:23PM +0800, Zhongze Liu wrote: >>> Hi Xen developers, >>> >>> In

Re: [Xen-devel] About the parameter list of tools/libxc/xc_domain.c:xc_domain_add_to_physmap()

2017-06-14 22:42 GMT+08:00 Wei Liu : > On Wed, Jun 14, 2017 at 09:19:23PM +0800, Zhongze Liu wrote: >> Hi Xen developers, >> >> In tools/libxc/xc_domain.c:xc_domain_add_to_physmap() the .size field >> of the xen_add_to_physmap >> struct can't be controlled by the caller

Re: [Xen-devel] About the parameter list of tools/libxc/xc_domain.c:xc_domain_add_to_physmap()

On Wed, Jun 14, 2017 at 03:42:34PM +0100, Wei Liu wrote: > On Wed, Jun 14, 2017 at 09:19:23PM +0800, Zhongze Liu wrote: > > Hi Xen developers, > > > > In tools/libxc/xc_domain.c:xc_domain_add_to_physmap() the .size field > > of the xen_add_to_physmap > > struct can't be controlled by the caller

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

On 14/06/17 17:01, Boris Ostrovsky wrote: > On 06/14/2017 11:00 AM, Juergen Gross wrote: >> On 14/06/17 16:48, Boris Ostrovsky wrote: diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c index 84106f9c456c..d641e9970d5d 100644 --- a/drivers/xen/sys-hypervisor.c

  1   2   >