Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen

[Wei Liu]

On Sun, Jan 31, 2016 at 10:09:07PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 29, 2016 at 10:34:59AM +, David Vrabel wrote:
> > On 29/01/16 02:31, Andy Lutomirski wrote:
> > > Signed-off-by: Andy Lutomirski 
> > > ---
> > >  drivers/virtio/virtio_ring.c | 12 
> > >  1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > index c169c6444637..305c05cc249a 100644
> > > --- a/drivers/virtio/virtio_ring.c
> > > +++ b/drivers/virtio/virtio_ring.c
> > > @@ -47,6 +47,18 @@
> > >  
> > >  static bool vring_use_dma_api(void)
> > >  {
> > > +#if defined(CONFIG_X86) && defined(CONFIG_XEN)
> > > + /*
> > > +  * In theory, it's possible to have a buggy QEMU-supposed
> > > +  * emulated Q35 IOMMU and Xen enabled at the same time.  On
> > > +  * such a configuration, virtio has never worked and will
> > > +  * not work without an even larger kludge.  Instead, enable
> > > +  * the DMA API if we're a Xen guest, which at least allows
> > > +  * all of the sensible Xen configurations to work correctly.
> > > +  */
> > > + return static_cpu_has(X86_FEATURE_XENPV);
> > 
> > You want:
> > 
> > if (xen_domain())
> > return true;
> > 
> > Without the #if so we use the DMA API for all types of Xen guest on all
> > architectures.
> > 
> > David
> 
> I doubt HVM domains can have virtio devices.
> 

Yes, they can.

When virtio-pci is used virtio device is just yet another pci device
emulated by QEMU.

Wei.

> -- 
> MST
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again

[Wei Liu]

On Mon, Feb 01, 2016 at 10:04:07AM -0800, Andy Lutomirski wrote:
> On Mon, Feb 1, 2016 at 3:00 AM, Wei Liu  wrote:
> > Nice work, Andy.
> >
> > On Thu, Jan 28, 2016 at 06:31:13PM -0800, Andy Lutomirski wrote:
> >> This switches virtio to use the DMA API on Xen and if requested by
> >> module option.
> >>
> >> This fixes virtio on Xen, and it should break anything because it's
> >> off by default on everything except Xen PV on x86.
> >>
> >
> > What is your setup? My understanding is that virtio doesn't work on PV
> > guest as of now because a suitable transport is missing.
> 
> I cheated and ran Xen under KVM with the virtio-pci device provided by
> QEMU.   If you have virtme
> (https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/), you can
> do:
> 

Thanks for the clarification. This is exactly what I needed to know.  In
that case virtio-pci transport is used.  All virtio devices are exposed
as PCI devices.

Wei.


> virtme-run --kdir=. --pwd --xen xen-4.5.2 --qemu-opts -smp 3 -m 1024
> 
> where xen-4.5.2 is the gunzipped Xen binary.  (Other versions work, too.)
> 
> --Andy

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 79622 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79622/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-prev  5 xen-build fail REGR. vs. 79422
 build-i3865 xen-buildfail in 79502 REGR. vs. 79422

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 79502

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail   like 79178
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 79379
 build-i386-rumpuserxen6 xen-buildfail   like 79422
 build-amd64-rumpuserxen   6 xen-buildfail   like 79422
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 79422

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)blocked in 79502 n/a
 build-i386-rumpuserxen1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-xl1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-libvirt   1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)  blocked in 79502 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)  blocked in 79502 n/a
 test-amd64-i386-pair  1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
79502 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-xl-raw1 build-check(1)blocked in 79502 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)  blocked in 79502 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked in 79502 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked in 79502 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1) blocked in 79502 n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 

Re: [Xen-devel] [PATCH v6 9/9] vring: Use the DMA API on Xen

[Wei Liu]

On Mon, Feb 01, 2016 at 10:00:59AM -0800, Andy Lutomirski wrote:
> Signed-off-by: Andy Lutomirski 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[PGNet Dev]

On 02/01/2016 11:14 AM, Boris Ostrovsky wrote:

Is 'HVMLite' replacing 'PVH'? Or are they separate modes?


Yes, HVMlite is replacing PVH. Probably once we get dom0 support.


If that's a 'done deal', and it sounds like it is, it'd be useful to 
have it integrated into:


  http://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum

particularly as there's no mention of HVMlite on the wiki, at all.

It's unclear whether PVH, in its current dev state (at least here), is 
worth-the-visit -- especially if HVMlite is "ComingSoon(tm)".


I suppose I'm looking for some guidance as to which to invest time in 
while on Xen 4.6.0, ack'ing that neither PVH nor HVMlite are 
production-ready.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[Boris Ostrovsky]

On 02/01/2016 10:49 AM, PGNet Dev wrote:

On 02/01/2016 06:11 AM, Boris Ostrovsky wrote:

This actually never happened for Linux: HVMlite showed up fast enough
that it didn't make sense anymore to add 32-bit support to Linux
(especially given that AMD was still not supported).


Is 'HVMLite' replacing 'PVH'? Or are they separate modes?


Yes, HVMlite is replacing PVH. Probably once we get dom0 support.

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[Boris Ostrovsky]

On 02/01/2016 11:56 AM, Jan Beulich wrote:

On 01.02.16 at 15:54,  wrote:


This looks very much like it needs backport of 33c19df9a ("x86/PCI:
intercept accesses to RO MMIO from dom0s in HVM containers") from
unstable, which fixes PVH regression introduced by 9256f66c1606
("x86/PCI: intercept all PV Dom0 MMCFG writes")

I don't really understand: The former was needed to fix an issue
introduced by the latter, but the latter isn't in 4.6 iirc.



I see it in 4.6, for example

http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6;pg=2

and search for "intercept all PV Dom0 MMCFG writes".

-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.14 test] 79698: regressions - FAIL

[osstest service owner]

flight 79698 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79698/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 78986
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 78986

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 78986
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 78986
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 78986

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linux757bcff73ad4726504a3f40d12a970a593249350
baseline version:
 linuxe9977508d75a36c78c2167800bc9d19d174f7585

Last test of basis78986  2016-01-25 05:54:32 Z7 days
Testing same since79397  2016-01-29 06:14:12 Z3 days4 attempts


People who touched revisions under test:
  Acked-by: David Howells 
  Alexandra Yates 
  Andrew Morton 
  Andrey Ryabinin 
  Andy Gospodarek 
  Arnd Bergmann 
  Ashish Panwar 
  Ben Hutchings 
  Boqun Feng 
  Boris Ostrovsky 
  Catalin Marinas 
  Charles Keepax 
  Charles Ouyang 
  Christoffer Dall 
  Chunfeng Yun 
  Cong Wang 
  Corey Minyard 
  Dan Carpenter 
  Darren Hart 
  David Henningsson 
  David S. Miller 
  David Vrabel 
  Dmitry V. Levin 
  Dmitry Vyukov 
  Eric Dumazet 
  Eric W. Biederman 
  Evan Jones 
  Florian Westphal 
  Francesco Ruggeri 
  Francesco Ruggeri 
  Greg Kroah-Hartman 
  Guenter Roeck 
  H. Peter Anvin 
  H.J. Lu 
  Hannes Frederic Sowa 
  Helge Deller 
  Herbert Xu 
  Ido Schimmel 
  Ingo Molnar 
  Ivaylo Dimitrov 
  Jan Stancek 
  Jay Vosburgh 
  Jiri Kosina 
  Jiri Pirko 
  Johan Hovold 
  John Blackwood 
  Karl Heiss 
  Linus Torvalds 
  Mans Rullgard 
  Marc Zyngier 
  Marcelo Ricardo Leitner 
  Mario Kleiner 
  Mark Brown 
  Mathias Nyman 
  Michael Ellerman 
  Michael Neuling 
  Mikulas Patocka 
  Neal Cardwell 
  Nicolas Boichat 
  Nikesh Oswal 
  Oliver Freyermuth 
  Oliver Neukum 
  Ouyang Zhaowei (Charles) 
  Paul Mackerras 
  Paul Mackerras 
  Peter Zijlstra (Intel) 
  Richard Purdie 
  Sachin Pandhare 
  Sasha Levin 
  Steven Rostedt 

Re: [Xen-devel] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Alex Williamson]

On Mon, 2016-02-01 at 13:49 +0100, Gerd Hoffmann wrote:
> > > Maybe we should define the interface as "guest writes 0xfc to pick
> > > address, qemu takes care to place opregion there".  That gives us the
> > > freedom to change the qemu implementation (either copy host opregion or
> > > map the host opregion) without breaking things.
> > 
> > Ok, so seabios allocates two pages, writes the base address of those
> > pages to 0xfc and looks to see whether the signature appears at that
> > address due to qemu mapping.  It verifies the size and does a
> > free/realloc if not the right size.
> 
> I think seabios first needs to reserve something big enough for a
> temporary mapping, to check signature + size, otherwise the opregion
> might scratch data structures beyond opregion in case it happens to be
> larger than 8k.
> 
> How likely is it that the opregion size ever changes?  Should we better
> be prepared to handle it?  Or would it be ok to have a ...
> 
>    if (opregion_size > 8k)
>   panic();
> 
> ... style sanity check?
> 

The patch below is what I'm working with now, it assumes that the
opregion is 8K, maps, verifies, and re-allocs if it's a different size.
Maybe it is safer to abort if it is over 8K, but we're not actually
clobbering anything with the mapping, we're just temporarily mapping
over it.  So if there's not another thread of execution that could be
accessing something there and we're not stepping on our own stack or
data, it doesn't seem like there's a problem.

diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
index c31c2fa..4f3251e 100644
--- a/src/fw/pciinit.c
+++ b/src/fw/pciinit.c
@@ -257,6 +257,52 @@ static void ich9_smbus_setup(struct pci_device *dev, void *
 pci_config_writeb(bdf, ICH9_SMB_HOSTC, ICH9_SMB_HOSTC_HST_EN);
 }
 
+static void intel_igd_opregion_setup(struct pci_device *dev, void *arg)
+{
+u16 bdf = dev->bdf;
+u32 orig;
+void *opregion;
+int size = 8;
+
+if (!CONFIG_QEMU)
+return;
+
+orig = pci_config_readl(bdf, 0xFC);
+
+realloc:
+opregion = malloc_high(size * 1024);
+if (!opregion) {
+warn_noalloc();
+return;
+}
+
+/*
+ * QEMU maps the OpRegion into system memory at the address written here,
+ * this overlaps our malloc, which marks the range e820 reserved.
+ */
+pci_config_writel(bdf, 0xFC, cpu_to_le32((u32)opregion));
+
+if (memcmp(opregion, "IntelGraphicsMem", 16)) {
+pci_config_writel(bdf, 0xFC, orig);
+free(opregion);
+return; /* the opregion didn't magically appear, not supported */
+}
+
+if (size == le32_to_cpu(*(u32 *)(opregion + 16))) {
+dprintf(1, "Intel IGD OpRegion enabled on %02x:%02x.%x\n",
+pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf));
+return; /* success! */
+}
+
+pci_config_writel(bdf, 0xFC, orig);
+free(opregion);
+
+if (size == 8) { /* try once more with a new size */
+size = le32_to_cpu(*(u32 *)(opregion + 16));
+goto realloc;
+}
+}
+
 static const struct pci_device_id pci_device_tbl[] = {
 /* PIIX3/PIIX4 PCI to ISA bridge */
 PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_0,
@@ -290,6 +336,10 @@ static const struct pci_device_id pci_device_tbl[] = {
 PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0017, 0xff00, apple_macio_setup),
 PCI_DEVICE_CLASS(PCI_VENDOR_ID_APPLE, 0x0022, 0xff00, apple_macio_setup),
 
+/* Intel IGD OpRegion setup */
+PCI_DEVICE_CLASS(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA,
+ intel_igd_opregion_setup),
+
 PCI_DEVICE_END,
 };
 

> > If the graphics signature does not
> > appear, free those pages and assume no opregion support.
> 
> Yes.
> 
> > If we later
> > decide to use a copy, we'd need to disable the 0xfc automagic mapping
> > and probably pass the data via fw_cfg.  Sound right?
> 
> I'd have qemu copy the data on 0xfc write then, so things continue to
> work without updating seabios.  So, the firmware has to allocate space,
> reserve it etc.,  and programming the 0xfc register.  Qemu has to make
> sure the opregion appears at the address written by the firmware, by
> whatever method it prefers.

Ah, so here is where we'd clobber data in firmware.  I currently do
this in vfio's pci config write in QEMU:

orig = pci_get_long(pdev->config + IGD_OPREGION);
pci_default_write_config(pdev, addr, val, len);
cur = pci_get_long(pdev->config + IGD_OPREGION);

if (cur != orig) {
if (orig) {
memory_region_del_subregion(get_system_memory(),
vdev->igd_opregion->mem);
}

if (cur) {
memory_region_add_subregion(get_system_memory(),
cur, vdev->igd_opregion->mem);
}
}

This means that fw can write 0x0 back to the ASL storage register and
the mapping goes away, no 

Re: [Xen-devel] Clarifying PVH mode requirements

[Brendan Gregg]

On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky  wrote:

> On 02/01/2016 02:27 PM, PGNet Dev wrote:
>
>> On 02/01/2016 11:14 AM, Boris Ostrovsky wrote:
>>
>>> Is 'HVMLite' replacing 'PVH'? Or are they separate modes?

>>>
>>> Yes, HVMlite is replacing PVH. Probably once we get dom0 support.
>>>
>>
>> If that's a 'done deal', and it sounds like it is, it'd be useful to have
>> it integrated into:
>>
>> http://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum
>>
>> particularly as there's no mention of HVMlite on the wiki, at all.
>>
>
Thanks, HVMlite is new to me. I created the Xen modes diagram on this page
(based on the older modes diagram; if anyone wants the new omnigraffle
source, email me), and I just created a Xen wiki account so I can update
this page. I've been meaning to update this modes diagram anyway, and
improve the columns.


> HVMlite is very new: domU hypervisor support has been added less than two
> months ago and Linux patches are being reviewed as we speak (FreeBSD, I
> believe, is supported).
>
>
>> It's unclear whether PVH, in its current dev state (at least here), is
>> worth-the-visit -- especially if HVMlite is "ComingSoon(tm)".
>>
>> I suppose I'm looking for some guidance as to which to invest time in
>> while on Xen 4.6.0, ack'ing that neither PVH nor HVMlite are
>> production-ready.
>>
>
> Current PVH implementation has never been described as production-ready.
> What is happening now with HVMlite is essentially bringing PVH to
> production-quality level.


So should I s/PVH/HVMlite/g? Or too much of a simlification? thanks,

Brendan

-- 
Brendan Gregg, Senior Performance Architect, Netflix
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 79772: regressions - FAIL

[osstest service owner]

flight 79772 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79772/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543

version targeted for testing:
 ovmf a65c44c9bbd26a6ea7699764882620677cc2eec6
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   55 days
Failing since 65593  2015-12-08 23:44:51 Z   55 days   59 attempts
Testing same since79772  2016-02-01 12:28:00 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Charles Duffy 
  Cinnamon Shia 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Michael Thomas 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Tapan Shah 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 7622 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/3] libxl: move begin phase job handling

[Jim Fehlig]

On 01/20/2016 12:00 PM, Joao Martins wrote:
> . From libxlMigrationBegin to libxlDomainMigrateBegin3Params().
> This is a preparatory patch to be able to begin a job in the
> perform phase.
>
> Signed-off-by: Joao Martins 
> ---
>  src/libxl/libxl_driver.c| 18 +-
>  src/libxl/libxl_migration.c | 16 +++-
>  2 files changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index d34f843..28220b2 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -5187,6 +5187,8 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
>  {
>  const char *xmlin = NULL;
>  virDomainObjPtr vm = NULL;
> +libxlDriverPrivatePtr driver;
> +char *ret;
>  
>  #ifdef LIBXL_HAVE_NO_SUSPEND_RESUME
>  virReportUnsupportedError();
> @@ -5223,7 +5225,21 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
>  return NULL;
>  }
>  
> -return libxlDomainMigrationBegin(domain->conn, vm, xmlin);
> +driver = domain->conn->privateData;
> +if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY) < 0) {
> +virObjectUnlock(vm);
> +return NULL;
> +}
> +
> +ret = libxlDomainMigrationBegin(domain->conn, vm, xmlin);
> +
> +if (!libxlDomainObjEndJob(driver, vm))
> +vm = NULL;

IIRC the qemu driver handles this a bit differently, and probably more
correctly. On the sender, a job is started during the begin phase and ended in
the confirm phase. On the receiver, a job is started in the prepare phase and
ended in the finish phase. This prevents modifying the virDomainObj between
phases, e.g. the begin and perform phases on the sender. Is it possible to
change the job handling similarly in the libxl migration phases?

Regards,
Jim


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-next test] 79738: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 79738 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79738/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 79587
 test-armhf-armhf-libvirt-qcow2  6 xen-bootfail REGR. vs. 79587
 test-amd64-amd64-qemuu-nested-intel  9 debian-hvm-install fail REGR. vs. 79587
 test-amd64-amd64-xl-qemuu-win7-amd64 12 guest-saverestore fail REGR. vs. 79587
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 79587
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail REGR. vs. 79587

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl   8 leak-check/basis(8)  fail blocked in 79587
 test-armhf-armhf-xl-cubietruck  8 leak-check/basis(8)fail blocked in 79587
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 79587
 test-armhf-armhf-xl-vhd   8 leak-check/basis(8)  fail blocked in 79587
 build-amd64-rumpuserxen   6 xen-buildfail   like 79587
 test-amd64-amd64-xl  15 guest-localmigrate   fail   like 79587
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail  like 79587
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail   like 79587
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail   like 79587
 build-i386-rumpuserxen6 xen-buildfail   like 79587
 test-amd64-amd64-xl-credit2  15 guest-localmigrate   fail   like 79587
 test-amd64-amd64-xl-xsm  15 guest-localmigrate   fail   like 79587
 test-amd64-i386-xl   15 guest-localmigrate   fail   like 79587
 test-amd64-amd64-xl-rtds 15 guest-localmigrate   fail   like 79587
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail   like 79587
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail   like 79587
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail like 
79587
 test-amd64-amd64-pair   22 guest-migrate/dst_host/src_host fail like 79587
 test-amd64-i386-pair22 guest-migrate/dst_host/src_host fail like 79587
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail   like 79587
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail like 79587

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux99e832465a3499fc50d5d8d41ff8fb6e3944767d
baseline version:
 linuxad0b40fa944628d6f30b40266a599b285d70a266

Last test of basis  (not found) 
Failing since 0  1970-01-01 00:00:00 Z 16833 days
Testing same since79738  2016-02-01 09:19:47 Z0 days1 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm 

Re: [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Kay, Allen M]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Sunday, January 31, 2016 9:42 AM
> To: Kay, Allen M; Gerd Hoffmann; David Woodhouse
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; qemu-de...@nongnu.org; Cao jin; vfio-
> us...@redhat.com
> Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset
> tweaks
> 
> On Sat, 2016-01-30 at 01:18 +, Kay, Allen M wrote:
> >
> > > -Original Message-
> > > From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex
> > > Williamson
> > > Sent: Friday, January 29, 2016 10:00 AM
> > > To: Gerd Hoffmann
> > > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo
> > > Habkost; Stefano Stabellini; qemu-de...@nongnu.org; Cao jin; vfio-
> > > us...@redhat.com
> > > Subject: Re: [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough
> > > chipset tweaks
> > >
> > > Do guest drivers depend on IGD appearing at 00:02.0?  I'm currently
> > > testing for any Intel VGA device, but I wonder if I should only be
> > > enabling anything opregion if it also appears at a specific address.
> > >
> >
> > No.  Both Windows and Linux IGD driver should work at any PCI slot.  We
> have seen 0:5.0 in the guest and the driver works.
> 
> Thanks Allen.  Another question, when I boot a VM with an assigned HD
> P4000 GPU, my console stream with IOMMU faults, like:
> 
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> DMAR: DMAR:[DMA Write] Request device [00:02.0] fault addr 9fa3
> 
> All of these fall within the host RMRR range for the device:
> 
> DMAR: Setting RMRR:
> DMAR: Setting identity map for device :00:02.0 [0x9f80 - 0xaf9f]

Hi Alex,

Do you configure IGD as primary or secondary display in your KVM setup?   If 
primary, are you running Intel vBIOS as part of guest boot?

On BDW/SKL systems, we have started to configure IGD as secondary and QEMU VGA 
and primary.  In this setup, we are no longer running vBIOS in the guest which 
avoids some complications.  vBIOS uses stolen memory for display buffers which 
requires RMRR mapping.  We have been using similar setup (IGD as secondary) on 
other hypervisors and have not seen IOMMU faults.

I will setup a KVM configuration on my SKL and see if I can duplicate your 
problem here.   I will try to call into Don's Thursday meeting to discuss this 
(I'm on call for jury duty this week).  I will give you a heads up on Wednesday 
evening.

Allen

> 
> A while back, we excluded devices using RMRRs from participating in IOMMU
> API domains because they may continue to DMA to these reserved regions
> after assignment, possibly corrupting VM memory (c875d2c1b808).  Intel
> later decided this exclusion shouldn't apply to graphics devices
> (18436afdc11a).  Don't the above IOMMU faults reveal that exactly the
> problem we're trying to prevent by general exclusion of RMRR encumbered
> devices from the IOMMU API is actually occuring?  If I were to have VM
> memory within the RMRR address range, I wouldn't be seeing these faults,
> I'd be having the GPU corrupt my VM memory.
> 
> David notes in the latter commit above:
> 
> "We should be able to successfully assign graphics devices to guests too, as
> long as the initial handling of stolen memory is reconfigured appropriately."
> 
> What code is supposed to be doing that reconfiguration when a device is
> assigned?  Clearly we don't have it yet, making assignment of these devices
> very unsafe.  It seems like vfio or IOMMU code  in the kernel needs device
> specific code to clear these settings to make it safe for userspace, then
> perhaps VM BIOS support to reallocate.  Is there any consistency across IGD
> revisions for doing this?  Is there a spec?
> Thanks,
> 
> Alex

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.14 baseline-only test] 38719: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38719 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38719/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 38705
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 38705

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 38705
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38705

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass

version targeted for testing:
 linux757bcff73ad4726504a3f40d12a970a593249350
baseline version:
 linuxe9977508d75a36c78c2167800bc9d19d174f7585

Last test of basis38705  2016-01-26 17:25:42 Z6 days
Testing same since38719  2016-02-01 09:51:40 Z0 days1 attempts


People who touched revisions under test:
  Acked-by: David Howells 
  Alexandra Yates 
  Andrew Morton 
  Andrey Ryabinin 
  Andy Gospodarek 
  Arnd Bergmann 
  Ashish Panwar 
  Ben Hutchings 
  Boqun Feng 
  Boris Ostrovsky 
  Catalin Marinas 
  Charles Keepax 
  Charles Ouyang 
  Christoffer Dall 
  Chunfeng Yun 
  Cong Wang 
  Corey Minyard 
  Dan Carpenter 
  Darren Hart 
  David Henningsson 
  David S. Miller 
  David Vrabel 
  Dmitry V. Levin 
  Dmitry Vyukov 
  Eric Dumazet 
  Eric W. Biederman 
  Evan Jones 
  Florian Westphal 
  Francesco Ruggeri 
  Francesco Ruggeri 
  Greg Kroah-Hartman 
  Guenter Roeck 
  H. Peter Anvin 
  H.J. Lu 
  Hannes Frederic Sowa 
  Helge Deller 
  Herbert Xu 
  Ido Schimmel 
  Ingo Molnar 
  Ivaylo Dimitrov 
  Jan Stancek 
  Jay Vosburgh 
  Jiri Kosina 
  Jiri Pirko 
  Johan Hovold 
  John Blackwood 
  Karl Heiss 
  Linus Torvalds 
  Mans Rullgard 
  Marc Zyngier 
  Marcelo Ricardo Leitner 
  Mario Kleiner 
  Mark Brown 
  Mathias Nyman 
  Michael Ellerman 
  Michael Neuling 
  Mikulas Patocka 
  Neal Cardwell 
  Nicolas Boichat 
  Nikesh Oswal 
  Oliver Freyermuth 
  Oliver Neukum 
  Ouyang Zhaowei (Charles) 
  Paul Mackerras 
  Paul Mackerras 

Re: [Xen-devel] [PATCH v3 1/3] libxl: add p2p migration

[Jim Fehlig]

On 01/20/2016 12:00 PM, Joao Martins wrote:
> Introduce support for VIR_MIGRATE_PEER2PEER in libvirt migration.
> Most of the changes occur at the source and no modifications
> at the receiver.
>
> In P2P mode there is only the Perform phase so we must handle
> the connection with the destination and actually perform the
> migration. libxlDomainPerformP2P implements the connection to
> the destination and let libxlDoMigrateP2P implements the actual
s/let//
> migration logic with virConnectPtr. In this function we take
> of doing all phases of migration in the destination similar to

"... take care of doing..." ?
> virDomainMigrateVersion3Full. We appropriately save the last
> error reported in each of the phases to provide proper
> reporting. We don't yet support VIR_MIGRATE_TUNNELED yet and

One of those "yet" can be dropped. Even as an native English speaker, I'm not
sure which one is the most correct to drop :-).

> we always use V3 with extensible params, thus it also makes the
> implementation simpler.
>
> It is worth noting that the receiver didn't have any changes,
> and since it's still the v3 sequence thus it is possible to
> migrate from a P2P to non-P2P host.
>
> Signed-off-by: Joao Martins 
> ---
> Changes since v2:
>  - Remove Connect Close callback
>
> Changes since v1:
>  - Move Begin step to libxlDoMigrateP2P to have all 4 steps
>   together.
>  - Remove if before VIR_FREE(dom_xml)
> ---
>  src/libxl/libxl_driver.c|  13 ++-
>  src/libxl/libxl_migration.c | 203 
> 
>  src/libxl/libxl_migration.h |  11 +++
>  3 files changed, 224 insertions(+), 3 deletions(-)

Looks good other than the commit message nits. I do have a question about the
job handling changes in 2 and 3 though.

Regards,
Jim


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

[Jan Beulich]

>>> On 01.02.16 at 09:03,  wrote:
> On 01/02/16 08:53, Jan Beulich wrote:
> On 01.02.16 at 05:54,  wrote:
>>> On 29/01/16 17:46, Jan Beulich wrote:
>>> On 29.01.16 at 17:26,  wrote:
> On Fri, Jan 29, 2016 at 09:00:15AM -0700, Jan Beulich wrote:
> On 29.01.16 at 16:30,  wrote:
>>> I am hoping the maintainers can guide me in how they would like:
>>>  - Deal with documentation? I removed the allowsuperpage from 
>>> documentation
>>>but perhaps it should just mention deprecated?
>>
>> Since you delete the option, deleting it from doc seems fine to me.
>>
>>>  - I left put_superpage as put_page_from_l2e calls it - but I can't see
>>>how the _PAGE_PSE bit would be set as you won't be able to even
>>>put that bit on (after my patch). Perhaps just make it an
>>>ASSERT in put_page_from_l2e?
>>
>> No, that can't be done. Did you check why it is the way it is
>> (having to do with the alternative initial P2M placement, which
>> does use superpages despite the guest itself not being able to
>> create any)?
>
> If I recall - this was done for P2M array when put in a different virtual
> address space? And this being only the initial domain - would this ..
> Oh this can be done for normal guests as well I presume?

 Iirc Jürgen enabled this for DomU too not so long ago.
>>>
>>> I did. The Xen tools won't use superpages for the p2m array, however.
>> 
>> That's unfortunate. Is there a reason for this?
> 
> It's a matter of complexity. Adding superpage usage for the p2m array
> would add quite some code to the tools without a real gain, as the domU
> will have to split the superpage in any case in order to be able to
> support migration of the domain. So the only gain would be to save
> about 0.2% of memory footprint while booting the kernel (when the kernel
> is up the difference would be zero).

Okay, makes sense. I just assumed that like in the Dom0 case
the code to set up the table would have been new anyway (due
to which in the Dom0 case it was actually natural to use large
pages where possible).

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] hap_invlpg() vs INVLPGA

[Egger, Christoph]

On 01/02/16 09:04, Jan Beulich wrote:
>>> This, otoh, reads as if you imply we intercept the L2's INVLPG.
>>> Yet the INVLPG intercept gets cleared when the domain uses
>>> NPT (and your original change also didn't alter any intercept
>>> settings). Hence I'm still lost how hap_invlpg() can be reached
>>> in that case other than via emulating INVLPG in the instruction
>>> emulator.
>>
>> svm_invlpg_intercept() and vmx_invlpg_intercept() call
>> paging_invlpg().  paging_invlpg() calls hap_invlpg()
>> as initialized in xen/arch/x86/mm/hap/hap.c
> 
> That's all fine, but according to my previous reply: How does
> execution reach svm_invlpg_intercept() when the INVLPG
> intercept gets disabled for domains using HAP (NPT)?

The intercept bitmask for L1 guest and L2 guest gets binary or'ed
when emulating the VMENTRY for the L1 guest.
That way you get also intercepts for the L1 hypervisor.

Christoph

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] hap_invlpg() vs INVLPGA

[Jan Beulich]

>>> On 29.01.16 at 18:09,  wrote:
> On 29/01/16 16:53, Jan Beulich wrote:
> On 29.01.16 at 15:02,  wrote:
>>> On 29/01/16 14:57, Egger, Christoph wrote:
 On 29/01/16 14:24, Jan Beulich wrote:
> Christoph,
>
> in commit dd6de3ab99 ("Implement Nested-on-Nested") you added
> code to hap_invlpg() supposedly emulating INVLPGA. I've been
> stumbling across this a number of times in the past, not being able
> to make the connection between (a) VMX/EPT and INVLPGA and
> (b) SVM's INVLPGA intercept and this function.

 When you boot Windows 7 as L1 guest and XP-Mode as L2 guest then
 L2 guest uses INVLPG instruction to invalidate a page and L1 guest
 handles this via using INVLPGA instruction.

 The INVLPG intercept flushes the nested hap p2m which is effectively
 a TLB flush to the L1 guest.
>>>
>>> ... actually to the L2 guest. Sorry for the typo.
>> 
>> So if the L1 guest does an INVLPGA, we should see an INVLPGA
>> intercept, not an INVLPG one.
> 
> INVLPG intercept comes first from L2 then INVLPGA from L1.

I.e. Xen's action should be in response to the intercepted INVLPGA,
which afaict wouldn't lead to hap_invlpg().

 Then this intercept is injected into L1 guest.
>> 
>> This, otoh, reads as if you imply we intercept the L2's INVLPG.
>> Yet the INVLPG intercept gets cleared when the domain uses
>> NPT (and your original change also didn't alter any intercept
>> settings). Hence I'm still lost how hap_invlpg() can be reached
>> in that case other than via emulating INVLPG in the instruction
>> emulator.
> 
> svm_invlpg_intercept() and vmx_invlpg_intercept() call
> paging_invlpg().  paging_invlpg() calls hap_invlpg()
> as initialized in xen/arch/x86/mm/hap/hap.c

That's all fine, but according to my previous reply: How does
execution reach svm_invlpg_intercept() when the INVLPG
intercept gets disabled for domains using HAP (NPT)?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

[Juergen Gross]

On 01/02/16 08:53, Jan Beulich wrote:
 On 01.02.16 at 05:54,  wrote:
>> On 29/01/16 17:46, Jan Beulich wrote:
>> On 29.01.16 at 17:26,  wrote:
 On Fri, Jan 29, 2016 at 09:00:15AM -0700, Jan Beulich wrote:
 On 29.01.16 at 16:30,  wrote:
>> I am hoping the maintainers can guide me in how they would like:
>>  - Deal with documentation? I removed the allowsuperpage from 
>> documentation
>>but perhaps it should just mention deprecated?
>
> Since you delete the option, deleting it from doc seems fine to me.
>
>>  - I left put_superpage as put_page_from_l2e calls it - but I can't see
>>how the _PAGE_PSE bit would be set as you won't be able to even
>>put that bit on (after my patch). Perhaps just make it an
>>ASSERT in put_page_from_l2e?
>
> No, that can't be done. Did you check why it is the way it is
> (having to do with the alternative initial P2M placement, which
> does use superpages despite the guest itself not being able to
> create any)?

 If I recall - this was done for P2M array when put in a different virtual
 address space? And this being only the initial domain - would this ..
 Oh this can be done for normal guests as well I presume?
>>>
>>> Iirc Jürgen enabled this for DomU too not so long ago.
>>
>> I did. The Xen tools won't use superpages for the p2m array, however.
> 
> That's unfortunate. Is there a reason for this?

It's a matter of complexity. Adding superpage usage for the p2m array
would add quite some code to the tools without a real gain, as the domU
will have to split the superpage in any case in order to be able to
support migration of the domain. So the only gain would be to save
about 0.2% of memory footprint while booting the kernel (when the kernel
is up the difference would be zero).

Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] hap_invlpg() vs INVLPGA

[Jan Beulich]

>>> On 01.02.16 at 09:14,  wrote:
> On 01/02/16 09:04, Jan Beulich wrote:
 This, otoh, reads as if you imply we intercept the L2's INVLPG.
 Yet the INVLPG intercept gets cleared when the domain uses
 NPT (and your original change also didn't alter any intercept
 settings). Hence I'm still lost how hap_invlpg() can be reached
 in that case other than via emulating INVLPG in the instruction
 emulator.
>>>
>>> svm_invlpg_intercept() and vmx_invlpg_intercept() call
>>> paging_invlpg().  paging_invlpg() calls hap_invlpg()
>>> as initialized in xen/arch/x86/mm/hap/hap.c
>> 
>> That's all fine, but according to my previous reply: How does
>> execution reach svm_invlpg_intercept() when the INVLPG
>> intercept gets disabled for domains using HAP (NPT)?
> 
> The intercept bitmask for L1 guest and L2 guest gets binary or'ed
> when emulating the VMENTRY for the L1 guest.
> That way you get also intercepts for the L1 hypervisor.

Okay, I can see this perhaps being correct (albeit unexpected)
for general1-intercepts (because all 32 bits are defined), but
clearly this is broken for e.g. general2-intercepts (where the
guest could set flags the hypervisor doesn't know about),
leading to the BUG() in nsvm_vmcb_guest_intercepts_exitcode().
Hence I didn't expect such behavior to be there in the first place.

And then this still doesn't make svm_invlpg_intercept() reachable:
While the L2 guest runs, the INVLPG intercept would be reflected
to the L1 guest. Whereas while the L1 guest runs, the intercept
would be off.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)

[Jan Beulich]

>>> On 30.01.16 at 02:47,  wrote:
> On Tue, Jan 26, 2016 at 04:37:05AM -0700, Jan Beulich wrote:
>> (re-adding xen-devel)
>> 
>> >>> On 26.01.16 at 12:28,  wrote:
>> > Iommu=0 let the whole Qubes system work, without enforcing hardware
>> > compartimentalisation (iommu is enforced in software mode)
>> > 
>> > When iommu=no-igfx is enforced, shell console boot up works flawlessly. All
>> > domu machines get booted up. A system hang will happen at the moment a domu
>> > machine does graphic rendering,
>> 
>> And this is (other than I originally implied) without passing through
>> the IGD to the DomU? If so, I can't see the difference between a
>> guest rendering to its display (and vncviewer or whatever frontend
>> you use converting this to rendering on the host) and rendering
>> which originates in the host.
> 
> Not sure if relevant, but window content is mapped from PV domU directly
> into X server (in dom0) address space, using xc_map_foreign_pages. It is
> done by hacking XShmAttach function. Not sure what graphics driver do
> with it next. Theoretically it could be possible that driver will direct IGD
> to do DMA directly from that place, but I guess it does not.

Interesting. This then really needs to be investigated from the
Qubes end rather than here. Possible resulting patches, if
relevant outside of that unusual setup, would then of course be
appreciated to be sent here.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 3/4] x86/xstate: fix fault behavior on XRSTORS

[Jan Beulich]

XRSTORS unconditionally faults when xcomp_bv has bit 63 clear. Instead
of just fixing this issue, overhaul the fault recovery code, which -
one of the many mistakes made when xstate support got introduced - was
blindly mirroring that accompanying FXRSTOR, neglecting the fact that
XRSTOR{,S} aren't all-or-nothing instructions. The new code, first of
all, does all the recovery actions in C, simplifying the inline
assembly used. And it does its work in a multi-stage fashion: Upon
first seeing a fault, state fixups get applied strictly based on what
architecturally may cause #GP. When seeing another fault despite the
fixups done, state gets fully reset. A third fault would then lead to
crashing the domain (instead of hanging the hypervisor in an infinite
loop of recurring faults).

Reported-by: Harmandeep Kaur 
Signed-off-by: Jan Beulich 
---
v2: Fix default MXCSR mask value. Avoid infinite fault recovery loop.

--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -29,6 +29,8 @@ unsigned int *__read_mostly xstate_sizes
 static unsigned int __read_mostly xstate_features;
 static unsigned int __read_mostly xstate_comp_offsets[sizeof(xfeature_mask)*8];
 
+static uint32_t __read_mostly mxcsr_mask = 0xffbf;
+
 /* Cached xcr0 for fast read */
 static DEFINE_PER_CPU(uint64_t, xcr0);
 
@@ -342,6 +344,7 @@ void xrstor(struct vcpu *v, uint64_t mas
 uint32_t hmask = mask >> 32;
 uint32_t lmask = mask;
 struct xsave_struct *ptr = v->arch.xsave_area;
+unsigned int faults, prev_faults;
 
 /*
  * AMD CPUs don't save/restore FDP/FIP/FOP unless an exception
@@ -361,35 +364,84 @@ void xrstor(struct vcpu *v, uint64_t mas
 /*
  * XRSTOR can fault if passed a corrupted data block. We handle this
  * possibility, which may occur if the block was passed to us by control
- * tools or through VCPUOP_initialise, by silently clearing the block.
+ * tools or through VCPUOP_initialise, by silently adjusting state.
  */
-switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
+for ( prev_faults = faults = 0; ; prev_faults = faults )
 {
+switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
+{
 #define XRSTOR(pfx) \
 alternative_io("1: .byte " pfx "0x0f,0xae,0x2f\n" \
+   "3:\n" \
"   .section .fixup,\"ax\"\n" \
-   "2: mov %[size],%%ecx\n" \
-   "   xor %[lmask_out],%[lmask_out]\n" \
-   "   rep stosb\n" \
-   "   lea %[mem],%[ptr]\n" \
-   "   mov %[lmask_in],%[lmask_out]\n" \
-   "   jmp 1b\n" \
+   "2: inc%z[faults] %[faults]\n" \
+   "   jmp 3b\n" \
"   .previous\n" \
_ASM_EXTABLE(1b, 2b), \
".byte " pfx "0x0f,0xc7,0x1f\n", \
X86_FEATURE_XSAVES, \
-   ASM_OUTPUT2([ptr] "+" (ptr), [lmask_out] "+" 
(lmask)), \
-   [mem] "m" (*ptr), [lmask_in] "g" (lmask), \
-   [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size) \
-   : "ecx")
-
-default:
-XRSTOR("0x48,");
-break;
-case 4: case 2:
-XRSTOR("");
-break;
+   ASM_OUTPUT2([mem] "+m" (*ptr), [faults] "+g" (faults)), 
\
+   [lmask] "a" (lmask), [hmask] "d" (hmask), \
+   [ptr] "D" (ptr))
+
+default:
+XRSTOR("0x48,");
+break;
+case 4: case 2:
+XRSTOR("");
+break;
 #undef XRSTOR
+}
+if ( likely(faults == prev_faults) )
+break;
+#ifndef NDEBUG
+gprintk(XENLOG_WARNING, "fault#%u: mxcsr=%08x\n",
+faults, ptr->fpu_sse.mxcsr);
+gprintk(XENLOG_WARNING, "xs=%016lx xc=%016lx\n",
+ptr->xsave_hdr.xstate_bv, ptr->xsave_hdr.xcomp_bv);
+gprintk(XENLOG_WARNING, "r0=%016lx r1=%016lx\n",
+ptr->xsave_hdr.reserved[0], ptr->xsave_hdr.reserved[1]);
+gprintk(XENLOG_WARNING, "r2=%016lx r3=%016lx\n",
+ptr->xsave_hdr.reserved[2], ptr->xsave_hdr.reserved[3]);
+gprintk(XENLOG_WARNING, "r4=%016lx r5=%016lx\n",
+ptr->xsave_hdr.reserved[4], ptr->xsave_hdr.reserved[5]);
+#endif
+switch ( faults )
+{
+case 1: /* Stage 1: Reset state to be loaded. */
+ptr->xsave_hdr.xstate_bv &= ~mask;
+/*
+ * Also try to eliminate fault reasons, even if this shouldn't be
+ * needed here (other code should ensure the sanity of the data).
+ */
+if ( ((mask & XSTATE_SSE) ||
+  ((mask & XSTATE_YMM) &&
+   !(ptr->xsave_hdr.xcomp_bv & XSTATE_COMPACTION_ENABLED))) )
+  

Re: [Xen-devel] [PATCH] MAINTAINERS: cover non-x86 vm_event files

[Ian Campbell]

On Sun, 2016-01-31 at 09:30 -0700, Tamas K Lengyel wrote:
> 
> 
> On Sun, Jan 31, 2016 at 2:07 AM, Razvan Cojocaru  om> wrote:
> > This patch covers modifications to xen/arch/*/vm_event.c, in order
> > to include ARM vm_event maintainership.
> > 
> > Signed-off-by: Razvan Cojocaru 
> Once vm_event.c is added to ARM:

I don't think that's a prerequisite for accepting this patch, is it? (In
some ways that's the point -- it covers all future ARCH vm_event.c)

> Acked-by: Tamas K Lengyel 

Acked-by: Ian Campbell 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[Wei Liu]

(Cc Roger)

On Sun, Jan 31, 2016 at 01:27:23PM -0800, PGNet Dev wrote:
> I run Xen 4.6 Dom0
> 
>   rpm -qa | egrep -i "kernel-default-4|xen-4"
>   kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64
>   xen-4.6.0_08-405.1.x86_64
> 
> My guests are currently HVM in PVHVM mode; I'm exploring PVH.
> 
> IIUC, for 4.6, this doc
> 
>   http://xenbits.xen.org/docs/4.6-testing/misc/pvh-readme.txt
> 

AIUI that document is not very up to date. 

In the mean time. There is another document in the same directory called
pvh.markdown that you can have a look.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-sid test] 38718: tolerable FAIL

[Platform Team regression test user]

flight 38718 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38718/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-sid-netboot-pvgrub 10 guest-start fail blocked in 38654
 test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail blocked in 
38654

baseline version:
 flight   38654

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  pass
 test-amd64-i386-amd64-sid-netboot-pygrub pass
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [COVERITY ACCESS] for Doug Goldstein

[Wei Liu]

On Fri, Jan 29, 2016 at 10:16:04AM -0600, Doug Goldstein wrote:
> Hi all,
> 
> I agree to the conditions in the Xen Project Security [1] and Coverity
> [2] Contribution guidelines.
> 
> I have been a Gentoo Linux developer since 2001 and involved with
> downstream packaging of virtualization products in Gentoo for at least 8
> years with a specific focus on QEMU, libvirt, KVM and now days Xen. I've
> been a libvirt contributor in the past (with commit access) but for the
> last year and half I've found my time consumed in other parts of the
> stack. Most recently I've been contributing to Xen. My day job for the
> last 8 years has been focused on shipping Linux based devices into
> hostile environments and improving the security so that we have some
> confidence that they are secure and untampered with. So I have a
> personal vested interest in ensuring security holes are plugged and not
> left around or provided to organizations with an interest in exploiting
> them. Because of this I would like access to the Coverity results to
> help plug anything that comes up.
> 
> My GPG key is not in the strong web of trust since I have very few
> signatures so I can understand if that's a hold up. I'll look forward to
> exchanging some signatures at the next Xen Developer Summit either way.
> 
> [1] http://www.xenproject.org/security-policy.html
> [2] http://xenproject.org/help/contribution-guidelines.html
> 
> -- 
> Doug Goldstein
> 

+1 for this.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xl: don't free additional memory on soft reset

[Wei Liu]

On Thu, Jan 28, 2016 at 11:58:25AM +0100, Vitaly Kuznetsov wrote:
> We don't need to free anything extra from Dom0 in order to perform soft
> reset. It can also fail soft reset if it happens that we don't have this
> memory (which we don't need) available.
> 
> Signed-off-by: Vitaly Kuznetsov 

Acked-by: Wei Liu 

> ---
>  tools/libxl/xl_cmdimpl.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 25507c7..20704d2 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2867,11 +2867,13 @@ start:
>  if (rc < 0)
>  goto error_out;
>  
> -ret = freemem(domid, _config.b_info);
> -if (ret < 0) {
> -fprintf(stderr, "failed to free memory for the domain\n");
> -ret = ERROR_FAIL;
> -goto error_out;
> +if (domid_soft_reset == INVALID_DOMID) {
> +ret = freemem(domid, _config.b_info);
> +if (ret < 0) {
> +fprintf(stderr, "failed to free memory for the domain\n");
> +ret = ERROR_FAIL;
> +goto error_out;
> +}
>  }
>  
>  libxl_asyncprogress_how autoconnect_console_how_buf;
> -- 
> 2.5.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices

[Ian Campbell]

On Sat, 2016-01-30 at 14:18 +0100, Tommi Airikka wrote:
> 
> 
> On Wed, Jan 27, 2016 at 7:30 PM, Konrad Rzeszutek Wilk  e.com> wrote:
> > On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote:
> > > Xen developers,
> > >
> > > After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed
> > > NIC stopped working.
> > > This bug was probably introduced in Debian Jessie sometime
> > > between 2015-12-30 and 2016-01-08 as 2015-12-30 as 2015-12-30 was the
> > > last time I upgraded without any problems according to my dpkg.log.
> > 
> > This upgrade looks to only have upgraded the hypervisor?
> > 
> > As in I see:
> > 
> > domU "bug" "uname -a":
> > Linux bug 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-
> > 02)
> > x86_64 GNU/Linux
> > 
> > domU "working" "uname -a":
> > Linux working 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2
> > (2016-01-02) x86_64 GNU/Linux
> > 
> > So same version? What was the earlier version of the hypervisor?
> I forgot to mention that I use apt-dater to upgrade both dom0 and domUs
> at the same time. domU "bug" was created for debugging purposes just a
> couple of hours after I used apt-dater and realized that there's
> something wrong with the pci passthrough. domU "bug" and domU "working"
> should have relatively similar software state.
> 
> According to dom0 dpkg.log, the xen-hypervisor-4.4-amd64 (version "4.4.1-
> 9+deb8u3") has been untouched since 2015-12-21.
> linux-image-3.16.0-4-amd64 was upgraded from "3.16.7-ckt20-1+deb8u1" to
> "3.16.7-ckt20-1+deb8u2" at the point of time when pci passthrough stopped
> working.
>  
> >  
> > The Xen version you have says:
> > > (XEN) I/O virtualisation disabled
> > 
> > Which is not very healthy for PCI passthrough. Albeit you can do
> > it with PV without IOMMU. Did the previous version of Xen have the same
> > message?
> I downgraded linux-image on dom0:
> dpkg -i linux-image-3.16.0-4-amd64_3.16.7-ckt20-1+deb8u1_amd64.deb
> 
> and now the pci passthrough seems to work!

The Debian changelog entry for the update says:

linux (3.16.7-ckt20-1+deb8u2) jessie-security; urgency=medium

  * [xen] Fix race conditions in back-end drivers (CVE-2015-8550, XSA-155)
  * [xen] pciback: Fix state validation in MSI control operations
(CVE-2015-8551, CVE-2015-8852, XSA-157)
  * pptp: verify sockaddr_len in pptp_bind() and pptp_connect() (CVE-2015-8569)
  * bluetooth: Validate socket address length in sco_sock_bind() (CVE-2015-8575)
  * ptrace: being capable wrt a process requires mapped uids/gids
(CVE-2015-8709)
  * KEYS: Fix race between read and revoke (CVE-2015-7550)
  * [x86] KVM: Reload pit counters for all channels when restoring state
(CVE-2015-7513)
  * udp: properly support MSG_PEEK with truncated buffers
(Closes: #808293, regression in 3.16.7-ckt17)
  * Revert "xhci: don't finish a TD if we get a short transfer event mid TD"
(Closes: #808602, #808953, regression in 3.16.7-ckt20)

The second bullet looks at first pretty interesting from this PoV,
see http://xenbits.xen.org/xsa/advisory-157.html for info on the XSA and
the various patches. Konrad is on the CC already so hopefully he has some
ideas.

I've attached the full Debian package diff from deb8u1 to u2, which has the
backported patches in it. Most of them (and all the Xen ones) have an
Origin header pointing to the upstream commit, looks like all of XSA-157
was applied and all but one (scsiback, not in this kernel) of XSA-155:

+Subject: [1/7] xen: Add RING_COPY_REQUEST()
+Origin: https://git.kernel.org/linus/454d5d882c7e412b840e3c99010fe81a9862f6fb
+Subject: [2/7] xen-netback: don't use last request to determine minimum Tx
+Origin: https://git.kernel.org/linus/0f589967a73f1f30ab4ac4dd9ce0bb399b4d6357
+Subject: [3/7] xen-netback: use RING_COPY_REQUEST() throughout
+Origin: https://git.kernel.org/linus/68a33bfd8403e4e22847165d149823a2e0e67c9c
+Subject: [4/7] xen-blkback: only read request operation from shared ring once
+Origin: https://git.kernel.org/linus/1f13d75ccb806260079e0679d55d9253e370ec8a
+Subject: [5/7] xen-blkback: read from indirect descriptors only once
+Origin: https://git.kernel.org/linus/18779149101c0dd43ded43669ae2a92d21b6f9cb
+Subject: [7/7] xen/pciback: Save xen_pci_op commands before processing it
+Origin: https://git.kernel.org/linus/8135cf8b092723dbfcc611fe6fdcb3a36c9951c5

+Subject: [1/5] xen/pciback: Return error on XEN_PCI_OP_enable_msi when device
+Origin: https://git.kernel.org/linus/56441f3c8e5bd45aab10dd9f8c505dd4bec03b0d
+Subject: [2/5] xen/pciback: Return error on XEN_PCI_OP_enable_msix when device
+Origin: https://git.kernel.org/linus/5e0ce1455c09dd61d029b8ad45d82e1ac0b6c4c9
+Subject: [3/5] xen/pciback: Do not install an IRQ handler for MSI interrupts.
+Origin: https://git.kernel.org/linus/a396f3a210c3a61e94d6b87ec05a75d0be2a60d0
+Subject: [4/5] xen/pciback: For XEN_PCI_OP_disable_msi[|x] only disable if
+Origin: 

[Xen-devel] Xen 4.7 Development Update

[Wei Liu]

This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.7 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming 4.7 timeline are as followed:

* Last posting date: March 18, 2016
* Hard code freeze: April 1, 2016
* RC1: TBD
* Release: June 3, 2016

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.7 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

= Projects =

== Hypervisor == 

*  Convert RTDS from time to event-driven model
  -  Meng Xu
  -  Tianyang Chen

=== x86 === 

*  CPUID handling improvement
  -  Andrew Cooper

*  VMWare tools support
  -  Don Slutz

*  xSplice, hypervisor hot-patching
  -  Konrad Wilk
  -  Ross Lagerwall

*  Porting Intel PState driver
  -  Wei Wang

*  HVMlite support
  -  Roger Pau Monne

*  Posted interrupt
  -  Wu, Feng

*  VMX TSC scaling support
  -  Haozhong Zhang

*  VT-d asynchronous flush issue
  -  Quan Xu

*  Memory protection-key support
  -  Huaitong Han

=== ARM === 

*  Guest save / restore support
  -  Ian Campbell

== Toolstack == 

*  vNVDIMM support
  -  Haozhong Zhang

*  Libxl PVSCSI support
  -  Olaf Hering

*  PV USB passthrough
  -  Chunyan Liu

*  HVM USB passthrough
  -  George Dunlap

*  QEMU based PVUSB backend
  -  Juergen Gross

*  Domain snapshot API
  -  Chunyan Liu

*  Fix hotplug script machinery and remove blktap
  -  George Dunlap

*  Basic xSplice tooling (see hypervisor item)
  -  Konrad Wilk

*  Load BIOS via toolstack
  -  Anthony Perard

*  Libxl depriv QEMU
  -  Ian Jackson

*  COLO
  -  Wen Congyang

== Documentation == 

*  Feature maturity lifecycle
  -  Lars Kurth

== Completed == 

*  Per-cpu reader-writer lock
  -  Malcolm Crossley

*  Make it easy to run xenstore in a domain
  -  Juergen Gross

*  Libxc support for migrating large PV domains
  -  Juergen Gross

*  Disentangle libxenctrl to stable libraries
  -  Ian Campbell

*  Use Kconfig to configure hypervisor components
  -  Doug Goldstein

*  vgic-v3
  -  Julien Grall

*  xsave/xrtors support
  -  Shuai Ruan

*  Toolstack-based soft reset
  -  Vitaly Kuznetsov

*  Libxc support for building large PV domains
  -  Juergen Gross

*  Run QEMU as non-root
  -  Stefano Stabellini

*  Intel CDP support
  -  He Chen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v6] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

When mapping large BARs (e.g. the frame buffer of a graphics card) the
overhead of establishing such mappings using only 4k pages has,
particularly after the XSA-125 fix, become unacceptable. Alter the
XEN_DOMCTL_memory_mapping semantics once again, so that there's no
longer a fixed amount of guest frames that represents the upper limit
of what a single invocation can map. Instead bound execution time by
limiting the number of iterations (regardless of page size).

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 
Acked-by: Kevin Tian 
---
Open issues (perhaps for subsequent changes):
- ARM side unimplemented (and hence libxc for now made cope with both
  models), the main issue (besides my inability to test any change
  there) being the many internal uses of map_mmio_regions())
- iommu_{,un}map_page() interfaces don't support "order" (hence
  mmio_order() for now returns zero when !iommu_hap_pt_share, which in
  particular means the AMD side isn't being taken care of just yet, but
  note that this also has the intended effect of suppressing non-zero
  order mappings in the shadow mode case)
---
v6: Move an mfn_valid() assertion to cover the full MFN range. Use
PAGE_ORDER_4K in mmio_order(). Improve the return value description
of set_typed_p2m_entry().
v5: Refine comment in domctl.h.
v4: Move cleanup duty entirely to the caller of the hypercall. Move
return value description to from commit message to domctl.h.
v3: Re-base on top of "x86/hvm: fold opt_hap_{2mb,1gb} into
hap_capabilities". Extend description to spell out new return value
meaning. Add a couple of code comments. Use PAGE_ORDER_4K instead
of literal 0. Take into consideration r/o MMIO pages.
v2: Produce valid entries for large p2m_mmio_direct mappings in
p2m_pt_set_entry(). Don't open code iommu_use_hap_pt() in
mmio_order(). Update function comment of set_typed_p2m_entry() and
clear_mmio_p2m_entry(). Use PRI_mfn. Add ASSERT()s to
{,un}map_mmio_regions() to detect otherwise endless loops.

--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2229,7 +2229,7 @@ int xc_domain_memory_mapping(
 {
 DECLARE_DOMCTL;
 xc_dominfo_t info;
-int ret = 0, err;
+int ret = 0, rc;
 unsigned long done = 0, nr, max_batch_sz;
 
 if ( xc_domain_getinfo(xch, domid, 1, ) != 1 ||
@@ -2254,19 +2254,24 @@ int xc_domain_memory_mapping(
 domctl.u.memory_mapping.nr_mfns = nr;
 domctl.u.memory_mapping.first_gfn = first_gfn + done;
 domctl.u.memory_mapping.first_mfn = first_mfn + done;
-err = do_domctl(xch, );
-if ( err && errno == E2BIG )
+rc = do_domctl(xch, );
+if ( rc < 0 && errno == E2BIG )
 {
 if ( max_batch_sz <= 1 )
 break;
 max_batch_sz >>= 1;
 continue;
 }
+if ( rc > 0 )
+{
+done += rc;
+continue;
+}
 /* Save the first error... */
 if ( !ret )
-ret = err;
+ret = rc;
 /* .. and ignore the rest of them when removing. */
-if ( err && add_mapping != DPCI_REMOVE_MAPPING )
+if ( rc && add_mapping != DPCI_REMOVE_MAPPING )
 break;
 
 done += nr;
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -436,7 +436,8 @@ static __init void pvh_add_mem_mapping(s
 else
 a = p2m_access_rw;
 
-if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i), a)) )
+if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i),
+  PAGE_ORDER_4K, a)) )
 panic("pvh_add_mem_mapping: gfn:%lx mfn:%lx i:%ld rc:%d\n",
   gfn, mfn, i, rc);
 if ( !(i & 0xf) )
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2491,7 +2491,7 @@ static int vmx_alloc_vlapic_mapping(stru
 share_xen_page_with_guest(pg, d, XENSHARE_writable);
 d->arch.hvm_domain.vmx.apic_access_mfn = mfn;
 set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE), _mfn(mfn),
-   p2m_get_hostp2m(d)->default_access);
+   PAGE_ORDER_4K, p2m_get_hostp2m(d)->default_access);
 
 return 0;
 }
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -899,48 +899,64 @@ void p2m_change_type_range(struct domain
 p2m_unlock(p2m);
 }
 
-/* Returns: 0 for success, -errno for failure */
+/*
+ * Returns:
+ *0  for success
+ *-errno for failure
+ *1 + new order  for caller to retry with smaller order (guaranteed
+ *   to be smaller than order passed in)
+ */
 static int set_typed_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn,
-   p2m_type_t gfn_p2mt, p2m_access_t access)
+   unsigned int order, p2m_type_t gfn_p2mt,
+   

Re: [Xen-devel] hap_invlpg() vs INVLPGA

[Jan Beulich]

>>> On 01.02.16 at 10:41,  wrote:
> On 01/02/16 10:00, Jan Beulich wrote:
> On 01.02.16 at 09:14,  wrote:
>>> On 01/02/16 09:04, Jan Beulich wrote:
>> This, otoh, reads as if you imply we intercept the L2's INVLPG.
>> Yet the INVLPG intercept gets cleared when the domain uses
>> NPT (and your original change also didn't alter any intercept
>> settings). Hence I'm still lost how hap_invlpg() can be reached
>> in that case other than via emulating INVLPG in the instruction
>> emulator.
>
> svm_invlpg_intercept() and vmx_invlpg_intercept() call
> paging_invlpg().  paging_invlpg() calls hap_invlpg()
> as initialized in xen/arch/x86/mm/hap/hap.c

 That's all fine, but according to my previous reply: How does
 execution reach svm_invlpg_intercept() when the INVLPG
 intercept gets disabled for domains using HAP (NPT)?
>>>
>>> The intercept bitmask for L1 guest and L2 guest gets binary or'ed
>>> when emulating the VMENTRY for the L1 guest.
>>> That way you get also intercepts for the L1 hypervisor.
>> 
>> Okay, I can see this perhaps being correct (albeit unexpected)
>> for general1-intercepts (because all 32 bits are defined), but
>> clearly this is broken for e.g. general2-intercepts (where the
>> guest could set flags the hypervisor doesn't know about),
>> leading to the BUG() in nsvm_vmcb_guest_intercepts_exitcode().
>> Hence I didn't expect such behavior to be there in the first place.
> 
> Whenever new intercepts get defined then those must be added.

I'm sorry, but no - this attitude is why nested mode can't be
expected to become supported any time soon. Unknown intercepts
must be explicitly filtered out and/or unknown L2 exits must be
handled gracefully (to at least the hypervisor).

>> And then this still doesn't make svm_invlpg_intercept() reachable:
>> While the L2 guest runs, the INVLPG intercept would be reflected
>> to the L1 guest. Whereas while the L1 guest runs, the intercept
>> would be off.
> 
> While this is correct, L0 hypervisor must flush the nested hap or
> whatever the L1 hypervisor does has no real effect to the L2 guest,
> otherwise because the TLB/MMU pagetable walk is not different.

I don't understand: You agree that svm_invlpg_intercept() is
unreachable when the guest uses HAP, but at the same time
you say that what it does is required for correct operation?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[Roger Pau Monné]

El 31/01/16 a les 22.27, PGNet Dev ha escrit:
> I run Xen 4.6 Dom0
> 
> rpm -qa | egrep -i "kernel-default-4|xen-4"
> kernel-default-devel-4.4.0-8.1.g9f68b90.x86_64
> xen-4.6.0_08-405.1.x86_64

Are your kernels compiled with CONFIG_PVH enabled?

> My guests are currently HVM in PVHVM mode; I'm exploring PVH.
> 
> IIUC, for 4.6, this doc
> 
> http://xenbits.xen.org/docs/4.6-testing/misc/pvh-readme.txt
> 
> instructs the following necessary changes:
> 
> @ GRUBG cfg
> 
> -GRUB_CMDLINE_XEN=" ..."
> +GRUB_CMDLINE_XEN=" dom0pvh ..."
> 
> &, @ guest.cfg
> 
> +pvh = 1
> 
> For my guest.cfg, currently in PVHVM mode, I have
> 
> builder = 'hvm'
> xen_platform_pci = 1
> device_model_version="qemu-xen"
> hap = 1
> ...
> 
> Q:
> Do any of these^^ params need to also change with the addition of
> 
> pvh = 1

Yes, you need to remove builder, xen_platform_pci and
device_model_version, and add a kernel and ramdisk parameters that point
to the actual kernel and ramdisk that you want to use. The file should
look like:

kernel = "/path/to/kernel"
ramdisk = "/path/to/ramdisk"
pvh=1
hap=1

[... other options, memory, vcpus ...]

The paths in the kernel and ramdisk options are relative to Dom0, not
DomU. You can also use pygrub if you prefer, by removing the
kernel/ramdisk options and setting the bootloader one:

bootloader="pygrub"

> 
>> At the moment HAP is required for PVH.
> 
> As above, I've 'hap = 1' enabled.
> 
> But checking cpu,
> 
> hwinfo --cpu | egrep "Arch|Model"
>   Arch: X86-64
>   Model: 6.60.3 "Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz"

You CPU is perfectly capable of running both a PVH Dom0 or DomU, check:

http://ark.intel.com/products/52269/Intel-Xeon-Processor-E3-1220-8M-Cache-3_10-GHz

Look for EPT and VT-d which are the main requirements for PVH.

> Q:
> Am I out of luck re: PVH with more modern Haswell? Or is there a
> different check I should be running ?
> 
>> At present the only PVH guest is an x86 64bit PV linux.
> 
> Is this still current/true info?

IIRC Boris (CCed) added support for 32bit PVH to Linux, so you should be
able to use either 32 or 64 kernels.

Roger.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC] xen/libxl/libxl: RIP PV superpage.

[Wei Liu]

You have two "libxl" in subject line.

On Fri, Jan 29, 2016 at 10:30:46AM -0500, Konrad Rzeszutek Wilk wrote:
> The last bastion of users is moving away from needing
> this.
> 
> Please note that there was an partial removal by
> c/s 9b3c6b13e0c085ceb53210f8e682a073096b94fa
> "libxc: remove superpages option for pv domains" so an user
> could not even run PV guests with superpage.
> 
> HVM guests are not affected - they have been able to use
> superpages (called hugepages) if the CPU supports 2MB or 1GB
> since Xen 3.3.
> 
> This is reported in the ring buffer:
> (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
> 
> AMD CPUs that support 2MB require NPT aka Rapid Virtualization
> Indexing. This was introduced in third generation Opteron -
> Barcelona.
> 
> Intel CPUs that support 2MB require EPT aka Extended Page Tables.
> This was introduced in Westmere microarchitecture.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  docs/misc/xen-command-line.markdown |   7 --
>  tools/libxc/include/xenguest.h  |   3 +-
>  tools/libxc/xc_nomigrate.c  |   2 +-
>  tools/libxc/xc_sr_restore.c |   6 +-
>  tools/libxl/libxl_internal.h|   2 +-
>  tools/libxl/libxl_save_callout.c|   4 +-
>  tools/libxl/libxl_save_helper.c |   3 +-
>  tools/libxl/libxl_stream_read.c |   2 +-

Changes to toolstack code are done only to internal functions and only
delete the extra argument for superpage flag. They look sensible.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86: shrink 'struct domain', was already PAGE_SIZE

[Corneliu ZUZU]

On 2/1/2016 12:47 PM, Jan Beulich wrote:

On 01.02.16 at 08:42,  wrote:

The X86 domain structure already occupied PAGE_SIZE (4096).

Looking @ the memory layout of the structure, we could see that
overall most was occupied by (used the pahole tool on domain.o):
  * sizeof(domain.arch) = sizeof(arch_domain) = 3328 bytes.
  * sizeof(domain.arch.hvm_domain) = 2224 bytes.
  * sizeof(domain.arch.hvm_domain.pl_time) = 1088 bytes.
This patch attempts to free some space, by making the pl_time
field in hvm_domain dynamically allocated.
We xzalloc/xfree it @ hvm_domain_initialise/hvm_domain_destroy.

After this change, the domain structure shrunk w/ 1152 bytes (>1K!).

Signed-off-by: Corneliu ZUZU 

Reviewed-by: Jan Beulich 
albeit ...


--- a/xen/include/asm-x86/hvm/vpt.h
+++ b/xen/include/asm-x86/hvm/vpt.h
@@ -139,6 +139,9 @@ struct pl_time {/* platform time */
  /* Ensures monotonicity in appropriate timer modes. */
  uint64_t last_guest_time;
  spinlock_t pl_time_lock;
+/* pl_time allocated dynamically, need to keep link to
+ * containing domain */
+struct domain *domain;
  };

... I wonder about the usefulness of this (malformed) comment. I'll
likely ditch it while committing.

Jan



Agreed, sorry about that and thanks.

Corneliu.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [linux-3.14 test] 79397: regressions - FAIL

[Ian Campbell]

On Sat, 2016-01-30 at 04:19 +, osstest service owner wrote:
> flight 79397 linux-3.14 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/79397/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 
> 78986
>  build-i386-rumpuserxen6 xen-build fail REGR. vs. 
> 78986

Force pushed as discussed in response to 79027.

> version targeted for testing:
>  linux757bcff73ad4726504a3f40d12a970a593249350
> baseline version:
>  linuxe9977508d75a36c78c2167800bc9d19d174f7585

(test-lab)osstest@osstest:~/branches/for-linux-3.14.git$ 
OSSTEST_CONFIG=production-config ./ap-push linux-3.14 
757bcff73ad4726504a3f40d12a970a593249350
+ branch=linux-3.14
+ revision=757bcff73ad4726504a3f40d12a970a593249350
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push linux-3.14 
757bcff73ad4726504a3f40d12a970a593249350
+ branch=linux-3.14
+ revision=757bcff73ad4726504a3f40d12a970a593249350
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.14
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x757bcff73ad4726504a3f40d12a970a593249350 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.14
++ : 

Re: [Xen-devel] [linux-3.10 test] 79465: regressions - FAIL

[Ian Campbell]

On Sun, 2016-01-31 at 14:02 +, osstest service owner wrote:
> flight 79465 linux-3.10 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/79465/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-rumpuserxen6 xen-build fail REGR. vs.
> 78980
>  build-amd64-rumpuserxen   6 xen-build fail REGR. vs.
> 78980

Force pushed per 79027.

> 
> version targeted for testing:
>  linuxe14ca734b547e3187713441909897aefdf4e4016
> baseline version:
>  linux14b58660bc26be42d272f7fb0d153ed8fc0a0c4e

(test-lab)osstest@osstest:~/branches/for-linux-3.10.git$ 
OSSTEST_CONFIG=production-config ./ap-push linux-3.10 
e14ca734b547e3187713441909897aefdf4e4016
+ branch=linux-3.10
+ revision=e14ca734b547e3187713441909897aefdf4e4016
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push linux-3.10 
e14ca734b547e3187713441909897aefdf4e4016
+ branch=linux-3.10
+ revision=e14ca734b547e3187713441909897aefdf4e4016
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.10
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' xe14ca734b547e3187713441909897aefdf4e4016 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.10
++ : daily-cron.linux-3.10
++ : 

Re: [Xen-devel] [PATCH RFC] Remove PV superpage support (v1).

[Ian Campbell]

On Fri, 2016-01-29 at 10:30 -0500, Konrad Rzeszutek Wilk wrote:
>  - Deal with documentation? I removed the allowsuperpage from
> documentation
>    but perhaps it should just mention deprecated?

"deprecated" means "still available but use is discouraged". Since AIUI you
really are removing PV superpages here calling it deprecated would be
wrong. I think you should just remove all mentions of it from the
documentation.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86: Convert shadow-paging to Kconfig

[Tim Deegan]

At 18:20 + on 29 Jan (1454091618), Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 

Acked-by: Tim Deegan 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[Roger Pau Monné]

El 01/02/16 a les 4.47, PGNet Dev ha escrit:
> In any case, the !st issue, prior to any guest being launched, simply
> adding
> 
>> @ GRUBG cfg
>>
>> -GRUB_CMDLINE_XEN=" ..."
>> +GRUB_CMDLINE_XEN=" dom0pvh ..."

Does your kernel support PVH mode (ie: CONFIG_PVH enabled?)

> causes boot fail,
> 
> ...
> (XEN) [2016-01-31 19:28:09] d0v0 EPT violation 0x1aa (-w-/r-x) gpa
> 0x00f100054c mfn 0xf15
> (XEN) [2016-01-31 19:28:09] d0v0 Walking EPT tables for GFN f1000:
> (XEN) [2016-01-31 19:28:09] d0v0  epte 800845108107
> (XEN) [2016-01-31 19:28:09] d0v0  epte 80085b680107
> (XEN) [2016-01-31 19:28:09] d0v0  epte 800844af7107
> (XEN) [2016-01-31 19:28:09] d0v0  epte 8050f1000905
> (XEN) [2016-01-31 19:28:09] d0v0  --- GLA 0xc96a254c
> (XEN) [2016-01-31 19:28:09] domain_crash called from vmx.c:2685
> (XEN) [2016-01-31 19:28:09] Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [2016-01-31 19:28:09] [ Xen-4.6.0_08-405  x86_64  debug=n
> Tainted:C ]
> (XEN) [2016-01-31 19:28:09] CPU:0
> (XEN) [2016-01-31 19:28:09] RIP:0010:[]
> (XEN) [2016-01-31 19:28:09] RFLAGS: 00010246   CONTEXT: hvm
> guest (d0v0)
> (XEN) [2016-01-31 19:28:09] rax: 000d   rbx:
> f100054c   rcx: 9e9f
> (XEN) [2016-01-31 19:28:09] rdx:    rsi:
> 0100   rdi: 81e0
> (XEN) [2016-01-31 19:28:09] rbp: 880164b57908   rsp:
> 880164b578d8   r8:  88016d88
> (XEN) [2016-01-31 19:28:09] r9:  0241   r10:
>    r11: 0001
> (XEN) [2016-01-31 19:28:09] r12: 0020   r13:
> 88016453aec0   r14: c96c
> (XEN) [2016-01-31 19:28:09] r15: 880164b57a20   cr0:
> 80050033   cr4: 
> (XEN) [2016-01-31 19:28:09] cr3: 01e0b000   cr2: 
> (XEN) [2016-01-31 19:28:09] ds:    es:    fs:    gs: 
> ss:    cs: 0010
> (XEN) [2016-01-31 19:28:09] Guest stack trace from rsp=880164b578d8:
> (XEN) [2016-01-31 19:28:09]   Fault while accessing guest memory.
> (XEN) [2016-01-31 19:28:09] Hardware Dom0 crashed: rebooting machine in
> 5 seconds.
> ...
> 
> Removing the dom0pvh gets me back up & running.

You will have to post the full boot log (Xen + Linux), there's not
enough information here to diagnose the issue.

Roger.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86: shrink 'struct domain', was already PAGE_SIZE

[Jan Beulich]

>>> On 01.02.16 at 08:42,  wrote:
> The X86 domain structure already occupied PAGE_SIZE (4096).
> 
> Looking @ the memory layout of the structure, we could see that
> overall most was occupied by (used the pahole tool on domain.o):
>  * sizeof(domain.arch) = sizeof(arch_domain) = 3328 bytes.
>  * sizeof(domain.arch.hvm_domain) = 2224 bytes.
>  * sizeof(domain.arch.hvm_domain.pl_time) = 1088 bytes.
> This patch attempts to free some space, by making the pl_time
> field in hvm_domain dynamically allocated.
> We xzalloc/xfree it @ hvm_domain_initialise/hvm_domain_destroy.
> 
> After this change, the domain structure shrunk w/ 1152 bytes (>1K!).
> 
> Signed-off-by: Corneliu ZUZU 

Reviewed-by: Jan Beulich 
albeit ...

> --- a/xen/include/asm-x86/hvm/vpt.h
> +++ b/xen/include/asm-x86/hvm/vpt.h
> @@ -139,6 +139,9 @@ struct pl_time {/* platform time */
>  /* Ensures monotonicity in appropriate timer modes. */
>  uint64_t last_guest_time;
>  spinlock_t pl_time_lock;
> +/* pl_time allocated dynamically, need to keep link to
> + * containing domain */
> +struct domain *domain;
>  };

... I wonder about the usefulness of this (malformed) comment. I'll
likely ditch it while committing.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again

[Wei Liu]

Nice work, Andy.

On Thu, Jan 28, 2016 at 06:31:13PM -0800, Andy Lutomirski wrote:
> This switches virtio to use the DMA API on Xen and if requested by
> module option.
> 
> This fixes virtio on Xen, and it should break anything because it's
> off by default on everything except Xen PV on x86.
> 

What is your setup? My understanding is that virtio doesn't work on PV
guest as of now because a suitable transport is missing.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

[Wei Liu]

On Thu, Jan 28, 2016 at 01:58:07PM -0700, Tamas K Lengyel wrote:
> The altp2m subsystem in its current form uses its own HVMOP hypercall to set
> mem_access permissions, duplicating some of the code already present for
> setting regular mem_access permissions. In this patch we consolidate the two
> and update the corresponding tools.
> 
> Signed-off-by: Tamas K Lengyel 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> Cc: Razvan Cojocaru 
> Cc: Stefano Stabellini 
> Cc: Keir Fraser 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> ---
> v2: Don't deprecate the HVMOP hypercall for setting mem_access
> Use unsigned int instead of unsigned long
> ---
>  tools/libxc/include/xenctrl.h   |   5 +-
>  tools/libxc/xc_altp2m.c |  25 --
>  tools/libxc/xc_mem_access.c |  14 +--
>  tools/tests/xen-access/xen-access.c |  53 ---

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] hap_invlpg() vs INVLPGA

[Egger, Christoph]

On 01/02/16 10:00, Jan Beulich wrote:
 On 01.02.16 at 09:14,  wrote:
>> On 01/02/16 09:04, Jan Beulich wrote:
> This, otoh, reads as if you imply we intercept the L2's INVLPG.
> Yet the INVLPG intercept gets cleared when the domain uses
> NPT (and your original change also didn't alter any intercept
> settings). Hence I'm still lost how hap_invlpg() can be reached
> in that case other than via emulating INVLPG in the instruction
> emulator.

 svm_invlpg_intercept() and vmx_invlpg_intercept() call
 paging_invlpg().  paging_invlpg() calls hap_invlpg()
 as initialized in xen/arch/x86/mm/hap/hap.c
>>>
>>> That's all fine, but according to my previous reply: How does
>>> execution reach svm_invlpg_intercept() when the INVLPG
>>> intercept gets disabled for domains using HAP (NPT)?
>>
>> The intercept bitmask for L1 guest and L2 guest gets binary or'ed
>> when emulating the VMENTRY for the L1 guest.
>> That way you get also intercepts for the L1 hypervisor.
> 
> Okay, I can see this perhaps being correct (albeit unexpected)
> for general1-intercepts (because all 32 bits are defined), but
> clearly this is broken for e.g. general2-intercepts (where the
> guest could set flags the hypervisor doesn't know about),
> leading to the BUG() in nsvm_vmcb_guest_intercepts_exitcode().
> Hence I didn't expect such behavior to be there in the first place.

Whenever new intercepts get defined then those must be added.

> And then this still doesn't make svm_invlpg_intercept() reachable:
> While the L2 guest runs, the INVLPG intercept would be reflected
> to the L1 guest. Whereas while the L1 guest runs, the intercept
> would be off.

While this is correct, L0 hypervisor must flush the nested hap or
whatever the L1 hypervisor does has no real effect to the L2 guest,
otherwise because the TLB/MMU pagetable walk is not different.

Christoph

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 79642 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79642/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 build-amd64   5 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 
66399
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 66399
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 66399

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never 

[Xen-devel] [PATCH] x86/hvm: Fix use-after-free introduced by c/s 428607a

[Andrew Cooper]

c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced a
use-after-free error during domain destruction, because of the order in which
timers are torn down.

  (XEN) Xen call trace:
  (XEN)[] spinlock.c#check_lock+0x1e/0x40
  (XEN)[] _spin_lock+0x11/0x52
  (XEN)[] vpt.c#pt_lock+0x24/0x40
  (XEN)[] destroy_periodic_time+0x18/0x81
  (XEN)[] rtc_deinit+0x53/0x78
  (XEN)[] hvm_domain_destroy+0x52/0x69
  (XEN)[] arch_domain_destroy+0x1a/0x98
  (XEN)[] domain.c#complete_domain_destroy+0x6f/0x182
  (XEN)[] rcupdate.c#rcu_process_callbacks+0x144/0x1a6
  (XEN)[] softirq.c#__do_softirq+0x82/0x8d
  (XEN)[] do_softirq+0x13/0x15
  (XEN)[] entry.o#process_softirqs+0x21/0x30
  (XEN)
  (XEN)
  (XEN) 
  (XEN) Panic on CPU 3:
  (XEN) GENERAL PROTECTION FAULT
  (XEN) [error_code=]
  (XEN) 

Defer the freeing of d->arch.hvm_domain.pl_time until all timers have been
destroyed.

For safety, NULL out the pointers after freeing them, in an attempt to make
mistakes more obvious in the future.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Corneliu ZUZU 
---
 xen/arch/x86/hvm/hvm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24400d..38c65b3 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1674,8 +1674,10 @@ void hvm_domain_relinquish_resources(struct domain *d)
 void hvm_domain_destroy(struct domain *d)
 {
 xfree(d->arch.hvm_domain.io_handler);
+d->arch.hvm_domain.io_handler = NULL;
+
 xfree(d->arch.hvm_domain.params);
-xfree(d->arch.hvm_domain.pl_time);
+d->arch.hvm_domain.params = NULL;
 
 hvm_destroy_cacheattr_region_list(d);
 
@@ -1686,6 +1688,9 @@ void hvm_domain_destroy(struct domain *d)
 rtc_deinit(d);
 stdvga_deinit(d);
 vioapic_deinit(d);
+
+xfree(d->arch.hvm_domain.pl_time);
+d->arch.hvm_domain.pl_time = NULL;
 }
 
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 05/28] xen/arm: ITS: Port ITS driver to Xen

[vijayak]

From: Vijaya Kumar K 

The linux driver is based on 4.1 with below commit id

591e5bec13f15feb13fc445b6c9c59954711c4ac

Only following code from Linux ITS driver is ported
and compiled
 - LPI initialization
 - ITS configuration code
 - Physical command queue management
 - ITS command building

Also redistributor information is split into rdist and
rdist_prop structures.

The rdist_prop struct holds the redistributor common
information for all re-distributor and rdist struct
holds the per-cpu specific information.

This per-cpu rdist is defined as global and shared with
physical ITS driver.

Signed-off-by: Vijaya Kumar K 
---
v8: - Sorted and used u64 for all fields in command structure
v7:
  - Introduced back its_send_inv()
  - Fix coding styles
v6:
  - made dump_cmd() static and const parameter
  - Include commit 591e5bec13f15feb13fc445b6c9c59954711c4ac
"irqchip/gicv3-its: Fix mapping of LPIs to collections".
  - reodered its_alloc_lpi_tables() and its_lpi_init()
v5:
  - dump_cmd is called from its_flush_cmd
  - Added its_lpi_alloc_chunks, lpi_free, its_send_inv, its_send_mapd,
its_send_mapvi to this patch as these functions are ported from
linux and more logical to be in this patch.
For now these functions are non-static. Will be made static
when used.
  - Used this_cpu instead of per_cpu
  - Moved GITS_* definitions to git-its.h
v4: Major changes
  - Redistributor refactoring patch is merged
  - Fixed comments from v3 related to coding style and
removing duplicate code.
  - Target address is stored from bits[48:16] to avoid
shifting of target address while building ITS commands
  - Removed non-static functions
  - Removed usage of command builder functions
  - Changed its_cmd_block union to include mix of bit and unsigned
variable types to define ITS command structure
v3:
  - Only required changes from Linux ITS driver is ported
  - Xen coding style is followed.
---
 xen/arch/arm/gic-v3-its.c | 1026 +
 xen/arch/arm/gic-v3.c |   15 +-
 xen/include/asm-arm/gic-its.h |  288 +++
 xen/include/asm-arm/gic.h |1 +
 xen/include/asm-arm/gic_v3_defs.h |   46 ++
 5 files changed, 1371 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
new file mode 100644
index 000..dac3326
--- /dev/null
+++ b/xen/arch/arm/gic-v3-its.c
@@ -0,0 +1,1026 @@
+/*
+ * Copyright (C) 2013, 2014 ARM Limited, All Rights Reserved.
+ * Author: Marc Zyngier 
+ *
+ * Xen changes:
+ * Vijaya Kumar K 
+ * Copyright (C) 2014, 2015 Cavium Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define its_print(lvl, fmt, ...)  \
+printk(lvl "GIC-ITS:" fmt, ## __VA_ARGS__)
+
+#define its_err(fmt, ...) its_print(XENLOG_ERR, fmt, ## __VA_ARGS__)
+/* TODO: ratelimit for Xen messages */
+#define its_err_ratelimited(fmt, ...) \
+its_print(XENLOG_G_ERR, fmt, ## __VA_ARGS__)
+
+#define its_dbg(fmt, ...) \
+its_print(XENLOG_DEBUG, fmt, ## __VA_ARGS__)
+
+#define its_info(fmt, ...)\
+its_print(XENLOG_INFO, fmt, ## __VA_ARGS__)
+
+#define its_warn(fmt, ...)\
+its_print(XENLOG_WARNING, fmt, ## __VA_ARGS__)
+
+//#define DEBUG_GIC_ITS
+
+#ifdef DEBUG_GIC_ITS
+# define DPRINTK(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
+#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1 << 0)
+#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING   (1 << 0)
+
+/*
+ * The ITS structure - contains most of the infrastructure, with the
+ * msi_controller, the command queue, the collections, and the list of
+ * devices writing to it.
+ */
+struct its_node {
+spinlock_t  lock;
+struct list_headentry;
+void __iomem*base;
+paddr_t phys_base;
+paddr_t phys_size;
+its_cmd_block   *cmd_base;
+   

[Xen-devel] [PATCH v8 01/28] xen/arm: Add bitmap_find_next_zero_area helper function

[vijayak]

From: Vijaya Kumar K 

bitmap_find_next_zero_area helper function will be used
by physical ITS driver. This is imported from linux 4.2

Signed-off-by: Vijaya Kumar K 
Acked-by: Jan Beulich 
CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
---
v5: Ported from Linux 4.2.
Added bitmap_find_next_zero_area_off().
v4: Removed spaces and added tabs
Moved ALIGN macro to lib.h
v3: Moved changes to xen/common/bitmap.c and
xen/include/xen/bitmap.h
---
 xen/common/bitmap.c  |   39 +++
 xen/include/xen/bitmap.h |   16 
 xen/include/xen/lib.h|2 ++
 3 files changed, 57 insertions(+)

diff --git a/xen/common/bitmap.c b/xen/common/bitmap.c
index 61d1ea4..ad665d1 100644
--- a/xen/common/bitmap.c
+++ b/xen/common/bitmap.c
@@ -489,6 +489,45 @@ int bitmap_allocate_region(unsigned long *bitmap, int pos, 
int order)
 }
 EXPORT_SYMBOL(bitmap_allocate_region);
 
+/*
+ * bitmap_find_next_zero_area_off - find a contiguous aligned zero area
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @align_mask: Alignment mask for zero area
+ * @align_offset: Alignment offset for zero area.
+ *
+ * The @align_mask should be one less than a power of 2; the effect is that
+ * the bit offset of all zero areas this function finds plus @align_offset
+ * is multiple of that power of 2.
+ */
+unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask,
+unsigned long align_offset)
+{
+   unsigned long index, end, i;
+again:
+   index = find_next_zero_bit(map, size, start);
+
+   /* Align allocation */
+   index = ALIGN_MASK(index + align_offset, align_mask) - align_offset;
+
+   end = index + nr;
+   if (end > size)
+   return end;
+   i = find_next_bit(map, end, index);
+   if (i < end) {
+   start = i + 1;
+   goto again;
+   }
+   return index;
+}
+EXPORT_SYMBOL(bitmap_find_next_zero_area_off)
+
 #ifdef __BIG_ENDIAN
 
 void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h
index e2a3686..161f990 100644
--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -101,6 +101,22 @@ extern int bitmap_scnlistprintf(char *buf, unsigned int 
len,
 extern int bitmap_find_free_region(unsigned long *bitmap, int bits, int order);
 extern void bitmap_release_region(unsigned long *bitmap, int pos, int order);
 extern int bitmap_allocate_region(unsigned long *bitmap, int pos, int order);
+extern unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+   unsigned long size,
+   unsigned long start,
+   unsigned int nr,
+   unsigned long align_mask,
+   unsigned long align_offset);
+
+static inline unsigned long bitmap_find_next_zero_area(unsigned long *map,
+  unsigned long size,
+  unsigned long start,
+  unsigned int nr,
+  unsigned long align_mask)
+{
+   return bitmap_find_next_zero_area_off(map, size, start, nr,
+ align_mask, 0);
+}
 
 #define BITMAP_LAST_WORD_MASK(nbits)   \
 (  \
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 4258912..e7d9d95 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -55,6 +55,8 @@
 
 #define ROUNDUP(x, a) (((x) + (a) - 1) & ~((a) - 1))
 
+#define ALIGN_MASK(x, mask) (((x) + (mask)) & ~(mask))
+
 #define reserve_bootmem(_p,_l) ((void)0)
 
 struct domain;
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 21/28] xen/arm: ITS: Add GICR register emulation

[vijayak]

From: Vijaya Kumar K 

Emulate LPI related changes to GICR registers

Signed-off-by: Vijaya Kumar K 
---
v8: - Updated GICR_PROPBASER and GICR_PENDBASER only on enabling
  LPIs and added 32/64 bit reg access
- Allocated LPI property table of size supported by Xen.
- Moved LPI property table related variables to vgic from vits
  structure.
- Used Tasklet to parse LPI property table and update pending irq
  structures
- Check is made in INV command processing to wait for LPI
  property table update before returning.
v7: - Merged patch#23 to this patch. patch#23 is just one line.
- Add 32-bit access to GICR_TYPER register
- Changed dprintk to printk
- LPI property table is handling is changed. Call {enable,disable}_lpi
  only for nr_lpis.
- Changes to GICD_TYPER emulation.
v6: - Moved LPI handling code to vgic-v3.c
- parse LPI property table on GICR_PROPBASER update
- use vgic_is_lpi_supported()
v5: - Handled all sizes access to LPI configuration table
- Rename vits_unmap_lpi_prop as  vits_map_lpi_prop
v4: - Added LPI configuration table emulation
- Rename function inline with vits
- Copied guest lpi configuration table to xen
---
 xen/arch/arm/vgic-v3-its.c|   18 ++
 xen/arch/arm/vgic-v3.c|  419 +++--
 xen/arch/arm/vgic.c   |   24 ++-
 xen/include/asm-arm/domain.h  |   31 +++
 xen/include/asm-arm/gic-its.h |1 +
 xen/include/asm-arm/gic_v3_defs.h |3 +
 xen/include/asm-arm/vgic.h|3 +
 7 files changed, 479 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 913b49d..1bb7674 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -23,12 +23,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -299,6 +301,22 @@ static int vits_process_discard(struct vcpu *v, struct 
vgic_its *vits,
 static int vits_process_inv(struct vcpu *v, struct vgic_its *vits,
 its_cmd_block *virt_cmd)
 {
+unsigned long flags;
+int state;
+
+/* Do no complete INV command until lpi property table
+ * is under update by tasklet
+ */
+do {
+spin_lock_irqsave(>domain->arch.vgic.prop_lock, flags);
+state = v->domain->arch.vgic.lpi_prop_table_state;
+spin_unlock_irqrestore(>domain->arch.vgic.prop_lock, flags);
+if ( state != LPI_TAB_IN_PROGRESS )
+break;
+cpu_relax();
+udelay(1);
+} while ( 1 );
+
 /* Ignored */
 DPRINTK("%pv vITS: INV: dev_id 0x%"PRIx32" id %"PRIu32"\n",
 v, virt_cmd->inv.devid, virt_cmd->inv.event);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2deed24..aa3c5ed 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -26,10 +26,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
 
 /*
@@ -159,6 +163,252 @@ static void vgic_store_irouter(struct domain *d, struct 
vgic_irq_rank *rank,
 rank->vcpu[offset] = new_vcpu->vcpu_id;
 }
 
+static void vgic_v3_disable_lpi(struct vcpu *v, uint32_t vlpi)
+{
+struct pending_irq *p;
+struct vcpu *v_target = v->domain->vcpu[0];
+
+p = irq_to_pending(v_target, vlpi);
+if ( test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+{
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+gic_remove_from_queues(v_target, vlpi);
+}
+}
+
+static void vgic_v3_enable_lpi(struct vcpu *v, uint32_t vlpi)
+{
+struct pending_irq *p;
+unsigned long flags;
+struct vcpu *v_target = vgic_get_target_vcpu(v, vlpi);
+
+p = irq_to_pending(v_target, vlpi);
+
+set_bit(GIC_IRQ_GUEST_ENABLED, >status);
+
+spin_lock_irqsave(_target->arch.vgic.lock, flags);
+
+if ( !list_empty(>inflight) &&
+ !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+gic_raise_guest_irq(v_target, vlpi, p->priority);
+
+spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
+}
+
+static int vgic_v3_gits_lpi_mmio_read(struct vcpu *v, mmio_info_t *info,
+  register_t *r, void *priv)
+{
+uint32_t offset;
+void *addr;
+unsigned long flags;
+struct hsr_dabt dabt = info->dabt;
+
+spin_lock_irqsave(>domain->arch.vgic.prop_lock, flags);
+
+offset = info->gpa -
+ (v->domain->arch.vgic.propbase & GICR_PROPBASER_PA_MASK);
+addr = (void *)((u8 *)v->domain->arch.vgic.prop_page + offset);
+
+switch (dabt.size)
+{
+case DABT_DOUBLE_WORD:
+*r = *((u64 *)addr);
+break;
+case DABT_WORD:
+*r = *((u32 *)addr);
+break;
+case DABT_HALF_WORD:
+*r = *((u16 *)addr);
+break;
+default:
+*r = *((u8 

[Xen-devel] [PATCH v8 23/28] xen/arm: ITS: Allocate pending_lpi descriptors for LPIs

[vijayak]

From: Vijaya Kumar K 

Allocate dynamically pending_lpi descriptors for LPIs

Signed-off-by: Vijaya Kumar K 
---
v8: - Dropped HAS_GICV3 config switch around pending_lpis[]
---
 xen/arch/arm/vgic-v3-its.c   |9 +
 xen/arch/arm/vgic.c  |   12 +---
 xen/include/asm-arm/domain.h |1 +
 xen/include/asm-arm/vgic.h   |1 +
 4 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 1bb7674..41e0b2a 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -890,6 +890,14 @@ int vits_domain_init(struct domain *d)
 
 vits = d->arch.vgic.vits;
 
+d->arch.vgic.pending_lpis = xzalloc_array(struct pending_irq,
+  d->arch.vgic.nr_lpis);
+if ( d->arch.vgic.pending_lpis == NULL )
+return -ENOMEM;
+
+for ( i = 0; i < d->arch.vgic.nr_lpis; i++ )
+vgic_init_pending_irq(>arch.vgic.pending_lpis[i], i + 
FIRST_GIC_LPI);
+
 spin_lock_init(>lock);
 
 vits->collections = xzalloc_array(struct its_collection,
@@ -918,6 +926,7 @@ int vits_domain_init(struct domain *d)
 
 void vits_domain_free(struct domain *d)
 {
+   xfree(d->arch.vgic.pending_lpis);
xfree(d->arch.vgic.vits->collections);
xfree(d->arch.vgic.vits);
 }
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 8d75d90..5b81583 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -73,7 +73,7 @@ static bool_t vgic_is_domain_lpi(struct domain *d, unsigned 
int lpi)
 (lpi < (d->arch.vgic.nr_lpis + FIRST_GIC_LPI)));
 }
 
-static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
+void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
 INIT_LIST_HEAD(>inflight);
 INIT_LIST_HEAD(>lr_queue);
@@ -446,13 +446,19 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
gic_sgi_mode irqmode, int
 
 struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
 {
-struct pending_irq *n;
+struct pending_irq *n = NULL;
 /* Pending irqs allocation strategy: the first vgic.nr_spis irqs
- * are used for SPIs; the rests are used for per cpu irqs */
+ * are used for SPIs; the rests are used for per cpu irqs.
+ * For LPIs pending_irq structures are allocated separately */
 if ( irq < 32 )
 n = >arch.vgic.pending_irqs[irq];
+else if ( vgic_is_domain_lpi(v->domain, irq) )
+n = >domain->arch.vgic.pending_lpis[irq - FIRST_GIC_LPI];
 else
 n = >domain->arch.vgic.pending_irqs[irq - 32];
+
+ASSERT(n != NULL);
+
 return n;
 }
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 48dcd9a..42182a6 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -102,6 +102,7 @@ struct arch_domain
  * struct arch_vcpu.
  */
 struct pending_irq *pending_irqs;
+struct pending_irq *pending_lpis;
 /* Base address for guest GIC */
 paddr_t dbase; /* Distributor base address */
 #ifdef CONFIG_HAS_GICV3
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 473fd8e..4711d3a 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -323,6 +323,7 @@ extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
enum gic_sgi_mode irqmode, int virq,
const struct sgi_target *target);
 extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int 
irq);
+extern void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq);
 
 /* Reserve a specific guest vIRQ */
 extern bool_t vgic_reserve_virq(struct domain *d, unsigned int virq);
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 26/28] xen/arm: ITS: Map ITS translation space

[vijayak]

From: Vijaya Kumar K 

ITS translation space contains GITS_TRANSLATER register
which is written by device to raise LPI. This space needs
to mapped to every domain address space for all physical
ITS available,so that device can access GITS_TRANSLATER
register using SMMU.

Signed-off-by: Vijaya Kumar K 
Acked-by: Ian Campbell 
---
v7: - Added comment on allowing CPU to access GITS_TRANSLATER
v6: - corrected typo in commit message
- Removed check for dom0
---
 xen/arch/arm/vgic-v3-its.c |   49 +++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index a265452..6809004 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -862,6 +862,53 @@ static const struct mmio_handler_ops 
vgic_gits_mmio_handler = {
 .write = vgic_v3_gits_mmio_write,
 };
 
+/*
+ * Map the 64K ITS translation space in guest.
+ * This is required purely for device smmu writes.
+*/
+
+static int vits_map_translation_space(struct domain *d)
+{
+uint64_t addr, size;
+int ret;
+
+ASSERT(is_domain_direct_mapped(d));
+
+addr = d->arch.vgic.vits->gits_base + SZ_64K;
+size = SZ_64K;
+
+/* For DomU translation space is mapped 1:1.
+ *
+ * As per spec IHI0069A, 8.1.3 there is undefined behavior when CPU
+ * writes to this register with wrong access size.
+ * Currently the page table are shared between the processor and the SMMU,
+ * So that means that a domain will be able to deadlock the processor
+ * and therefore the whole platform.
+ *
+ * TODO: A CPU should *never* be able to write to the GITS_TRANSLATER
+ * register. We have to make sure a guest cannot directly write to the HW.
+ * So we should never expose GITS_TRANSLATER into the processor page table.
+ * Which means we should not share page tables between the processor
+ * and the SMMU
+ *
+ * TODO: Also Handle DomU mapping
+ */
+ret = map_mmio_regions(d,
+   paddr_to_pfn(addr & PAGE_MASK),
+   DIV_ROUND_UP(size, PAGE_SIZE),
+   paddr_to_pfn(addr & PAGE_MASK));
+
+if ( ret )
+{
+ dprintk(XENLOG_G_ERR, "vITS: Unable to map to"
+ " 0x%"PRIx64" - 0x%"PRIx64" to dom%d\n",
+ addr & PAGE_MASK, PAGE_ALIGN(addr + size) - 1,
+ d->domain_id);
+}
+
+return ret;
+}
+
 int vits_domain_init(struct domain *d)
 {
 struct vgic_its *vits;
@@ -921,7 +968,7 @@ int vits_domain_init(struct domain *d)
 register_mmio_handler(d, _gits_mmio_handler, vits->gits_base,
   SZ_64K, NULL);
 
-return 0;
+return vits_map_translation_space(d);
 }
 
 void vits_domain_free(struct domain *d)
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 06/28] xen/arm: ITS: Add helper functions to manage its_devices

[vijayak]

From: Vijaya Kumar K 

Helper functions to manage its devices using RB-tree
are introduced in physical ITS driver.

This is global list of all the devices.

Signed-off-by: Vijaya Kumar K 
---
v8: - Added assert on lock in its_remove_device()
- Dropped Ack's from Ian and Julien
v7: - Introduce its_remove_device api to remove device
  from rb-tree
v5: - Added assert on spinlock
v4: - Remove passing of root node as parameter
- Declare prototype in header file
- Rename find_its_device to its_find_device
---
 xen/arch/arm/gic-v3-its.c |   61 +
 xen/include/asm-arm/gic-its.h |3 ++
 2 files changed, 64 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index dac3326..2716137 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -93,6 +93,8 @@ struct its_node {
 static LIST_HEAD(its_nodes);
 static DEFINE_SPINLOCK(its_lock);
 static struct rdist_prop  *gic_rdists;
+static struct rb_root rb_its_dev;
+static DEFINE_SPINLOCK(rb_its_dev_lock);
 
 #define gic_data_rdist()(this_cpu(rdist))
 
@@ -115,6 +117,63 @@ static struct its_collection *dev_event_to_col(struct 
its_device *dev,
 return its->collections + dev->event_map.col_map[event];
 }
 
+/* RB-tree helpers for its_device */
+static struct its_device *its_find_device(u32 devid)
+{
+struct rb_node *node = rb_its_dev.rb_node;
+
+ASSERT(spin_is_locked(_its_dev_lock));
+while ( node )
+{
+struct its_device *dev;
+
+dev = container_of(node, struct its_device, node);
+if ( devid < dev->device_id )
+node = node->rb_left;
+else if ( devid > dev->device_id )
+node = node->rb_right;
+else
+return dev;
+}
+
+return NULL;
+}
+
+static int its_insert_device(struct its_device *dev)
+{
+struct rb_node **new, *parent;
+
+ASSERT(spin_is_locked(_its_dev_lock));
+new = _its_dev.rb_node;
+parent = NULL;
+while ( *new )
+{
+struct its_device *this;
+
+this  = container_of(*new, struct its_device, node);
+parent = *new;
+if ( dev->device_id < this->device_id )
+new = &((*new)->rb_left);
+else if ( dev->device_id > this->device_id )
+new = &((*new)->rb_right);
+else
+return -EEXIST;
+}
+
+rb_link_node(>node, parent, new);
+rb_insert_color(>node, _its_dev);
+
+return 0;
+}
+
+static void its_remove_device(struct its_device *dev)
+{
+ASSERT(spin_is_locked(_its_dev_lock));
+
+if ( dev )
+rb_erase(>node, _its_dev);
+}
+
 #define ITS_CMD_QUEUE_SZSZ_64K
 #define ITS_CMD_QUEUE_NR_ENTRIES(ITS_CMD_QUEUE_SZ / sizeof(its_cmd_block))
 
@@ -953,6 +1012,8 @@ static int its_probe(struct dt_device_node *node)
 list_add(>entry, _nodes);
 spin_unlock(_lock);
 
+rb_its_dev = RB_ROOT;
+
 return 0;
 
 out_free_tables:
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 7f12d5b..c950097 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -19,6 +19,7 @@
 #define __ASM_ARM_GIC_ITS_H__
 
 #include 
+#include 
 
 /*
  * ITS registers, offsets from ITS_base
@@ -272,6 +273,8 @@ struct its_device {
 struct event_lpi_mapevent_map;
 /* Physical Device id */
 u32 device_id;
+/* RB-tree entry */
+struct rb_node  node;
 };
 
 int its_init(struct rdist_prop *rdists);
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 18/28] xen/arm: ITS: Export ITS info to Virtual ITS

[vijayak]

From: Vijaya Kumar K 

Export physical ITS information to virtual ITS driver

Signed-off-by: Vijaya Kumar K 
---
v8: - eventID_bits and devID_bits are made its node specific.
  Max of all the nodes is considered
- Moved assert on eventID_bits from its_assign_device()
  to its_add_device()
v7: - Moved gic_its_info from gic-its.h to gic-v3-its.c
- s/dev_bits/devID_bits
- s/eventid_bits/eventID_bits
- Dropped patch #20 and merged changes to this patch
- Enabled compilation of vITS driver
v6: - Passed only one physical ITS info
- Passed all the values as parameters
- Initialize vITS only if physical ITS is available
---
 xen/arch/arm/Makefile  |1 +
 xen/arch/arm/gic-v3-its.c  |   33 +
 xen/arch/arm/vgic-v3-its.c |   21 +
 xen/include/asm-arm/vits.h |2 ++
 4 files changed, 57 insertions(+)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 4970641..5cc4b37 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -34,6 +34,7 @@ obj-y += shutdown.o
 obj-y += traps.o
 obj-y += vgic.o vgic-v2.o
 obj-$(CONFIG_ARM_64) += vgic-v3.o
+obj-$(CONFIG_ARM_64) += vgic-v3-its.o
 obj-y += vtimer.o
 obj-y += vuart.o
 obj-y += hvm.o
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index fa88a75..e495d4d 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define its_print(lvl, fmt, ...)  \
@@ -86,8 +87,16 @@ struct its_node {
 u64 flags;
 u32 ite_size;
 struct dt_device_node   *dt_node;
+u8  eventID_bits;
+u8  devID_bits;
 };
 
+/* Contains common and collective data of all the its nodes. */
+static struct {
+u8 eventID_bits;
+u8 devID_bits;
+} its_data;
+
 #define ITS_ITT_ALIGNSZ_256
 
 static LIST_HEAD(its_nodes);
@@ -812,6 +821,8 @@ int its_add_device(u32 devid, u32 nr_ites, struct 
dt_device_node *dt_its)
 goto err_unlock;
 }
 
+ASSERT(dev->event_map.nr_lpis < (1 << dev->its->eventID_bits));
+
 BUG_ON(its_insert_device(dev));
 spin_unlock(_its_dev_lock);
 
@@ -915,6 +926,14 @@ int its_assign_device(struct domain *d, u32 vdevid, u32 
pdevid)
 return 0;
 }
 
+static void update_its_data(struct its_node *its)
+{
+if ( its_data.eventID_bits < its->eventID_bits )
+its_data.eventID_bits = its->eventID_bits;
+if ( its_data.devID_bits < its->devID_bits )
+its_data.devID_bits = its->devID_bits;
+}
+
 /*
  * We allocate 64kB for PROPBASE. That gives us at most 64K LPIs to
  * deal with (one configuration byte per interrupt). PENDBASE has to
@@ -1360,6 +1379,9 @@ static int its_probe(struct dt_device_node *node)
 its->phys_size = its_size;
 typer = readl_relaxed(its_base + GITS_TYPER);
 its->ite_size = ((typer >> 4) & 0xf) + 1;
+its->eventID_bits = GITS_TYPER_IDBITS(typer);
+its->devID_bits = GITS_TYPER_DEVBITS(typer);
+update_its_data(its);
 
 its->cmd_base = xzalloc_bytes(ITS_CMD_QUEUE_SZ);
 if ( !its->cmd_base )
@@ -1451,6 +1473,7 @@ int its_cpu_init(void)
 
 int __init its_init(struct rdist_prop *rdists)
 {
+struct its_node *its;
 struct dt_device_node *np = NULL;
 
 static const struct dt_device_match its_device_ids[] __initconst =
@@ -1473,6 +1496,16 @@ int __init its_init(struct rdist_prop *rdists)
 its_alloc_lpi_tables();
 its_lpi_init(rdists->id_bits);
 
+its = list_first_entry(_nodes, struct its_node, entry);
+/*
+ * As per vITS design spec, Xen exposes only one virtual ITS per domain.
+ * This simplifies vITS command model. I.e simplifies processing global
+ * ITS commands which does not have device ID on platform having more
+ * than one physical ITS.
+ */
+vits_setup_hw(its_data.devID_bits, its_data.eventID_bits,
+  its->phys_base, its->phys_size);
+
 return 0;
 }
 
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index bdcd9f1..36e6385 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -70,6 +70,26 @@ static void dump_cmd(const its_cmd_block *cmd)
 static void dump_cmd(const its_cmd_block *cmd) { }
 #endif
 
+static struct {
+bool_t enabled;
+uint8_t devID_bits;
+uint8_t eventID_bits;
+/* GITS physical base */
+paddr_t phys_base;
+/* GITS physical size */
+unsigned long phys_size;
+} vits_hw;
+
+void vits_setup_hw(uint8_t devID_bits, uint8_t eventID_bits,
+   paddr_t phys_base, unsigned long phys_size)
+{
+vits_hw.enabled = 1;
+vits_hw.devID_bits = devID_bits;
+vits_hw.eventID_bits = eventID_bits;
+vits_hw.phys_base = phys_base;
+vits_hw.phys_size = phys_size;
+}
+
 static inline uint16_t 

[Xen-devel] [PATCH v8 02/28] xen: Add log2 functionality

[vijayak]

From: Vijaya Kumar K 

log2 helper apis are ported from linux from
commit 13c07b0286d340275f2d97adf085cecda37ede37
(linux/log2.h: Fix rounddown_pow_of_two(1))
Changes made for xen are:
  - Only required functionality is retained
  - Replace fls_long with flsl

Signed-off-by: Vijaya Kumar K 
Acked-by: Jan Beulich 
CC: Ian Campbell 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
---
v4: - Only retained required functionality
- Replaced fls_long with flsl
- Removed fls_long implementation in bitops.h in v3 version
---
 xen/include/xen/log2.h |  167 
 1 file changed, 167 insertions(+)

diff --git a/xen/include/xen/log2.h b/xen/include/xen/log2.h
new file mode 100644
index 000..86bd861
--- /dev/null
+++ b/xen/include/xen/log2.h
@@ -0,0 +1,167 @@
+/* 
+ * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _XEN_LOG2_H
+#define _XEN_LOG2_H
+
+#include 
+#include 
+
+/*
+ * deal with unrepresentable constant logarithms
+ */
+extern __attribute__((const))
+int ilog2_NaN(void);
+
+/*
+ * non-constant log of base 2 calculators
+ * - the arch may override these in asm/bitops.h if they can be implemented
+ *   more efficiently than using fls() and fls64()
+ * - the arch is not required to handle n==0 if implementing the fallback
+ */
+static inline __attribute__((const))
+int __ilog2_u32(u32 n)
+{
+   return fls(n) - 1;
+}
+
+static inline __attribute__((const))
+int __ilog2_u64(u64 n)
+{
+   return flsl(n) - 1;
+}
+
+/*
+ * round up to nearest power of two
+ */
+static inline __attribute__((const))
+unsigned long __roundup_pow_of_two(unsigned long n)
+{
+   return 1UL << flsl(n - 1);
+}
+
+/**
+ * ilog2 - log of base 2 of 32-bit or a 64-bit unsigned value
+ * @n - parameter
+ *
+ * constant-capable log of base 2 calculation
+ * - this can be used to initialise global variables from constant data, hence
+ *   the massive ternary operator construction
+ *
+ * selects the appropriately-sized optimised version depending on sizeof(n)
+ */
+#define ilog2(n)   \
+(  \
+   __builtin_constant_p(n) ? ( \
+   (n) < 1 ? ilog2_NaN() : \
+   (n) & (1ULL << 63) ? 63 :   \
+   (n) & (1ULL << 62) ? 62 :   \
+   (n) & (1ULL << 61) ? 61 :   \
+   (n) & (1ULL << 60) ? 60 :   \
+   (n) & (1ULL << 59) ? 59 :   \
+   (n) & (1ULL << 58) ? 58 :   \
+   (n) & (1ULL << 57) ? 57 :   \
+   (n) & (1ULL << 56) ? 56 :   \
+   (n) & (1ULL << 55) ? 55 :   \
+   (n) & (1ULL << 54) ? 54 :   \
+   (n) & (1ULL << 53) ? 53 :   \
+   (n) & (1ULL << 52) ? 52 :   \
+   (n) & (1ULL << 51) ? 51 :   \
+   (n) & (1ULL << 50) ? 50 :   \
+   (n) & (1ULL << 49) ? 49 :   \
+   (n) & (1ULL << 48) ? 48 :   \
+   (n) & (1ULL << 47) ? 47 :   \
+   (n) & (1ULL << 46) ? 46 :   \
+   (n) & (1ULL << 45) ? 45 :   \
+   (n) & (1ULL << 44) ? 44 :   \
+   (n) & (1ULL << 43) ? 43 :   \
+   (n) & (1ULL << 42) ? 42 :   \
+   (n) & (1ULL << 41) ? 41 :   \
+   (n) & (1ULL << 40) ? 40 :   \
+   (n) & (1ULL << 39) ? 39 :   \
+   (n) & (1ULL << 38) ? 38 :   \
+   (n) & (1ULL << 37) ? 37 :   \
+   (n) & (1ULL << 36) ? 36 :   \
+   (n) & (1ULL << 35) ? 35 :   \
+   (n) & (1ULL << 34) ? 34 :   \
+   (n) & (1ULL << 33) ? 33 :   \
+   (n) & (1ULL << 32) ? 32 :   \
+   (n) & (1ULL << 31) ? 31 :   \
+   (n) & (1ULL << 30) ? 30 :   \
+   (n) & (1ULL << 29) ? 29 :   \
+   (n) & (1ULL << 28) ? 28 :   \
+   (n) & (1ULL << 27) ? 27 :   \
+   (n) & (1ULL << 26) ? 26 :   \
+   (n) & (1ULL << 25) ? 25 :   \
+   (n) & (1ULL << 24) ? 24 :   \
+   (n) & (1ULL << 23) ? 23 :   \
+   (n) & (1ULL << 22) ? 22 :   \
+   (n) & (1ULL << 21) ? 21 :   \
+   (n) & (1ULL << 20) ? 20 :   \
+   (n) & (1ULL << 

[Xen-devel] [PATCH v8 22/28] xen/arm: ITS: Allocate irq descriptors for LPIs

[vijayak]

From: Vijaya Kumar K 

Allocate dynamically irq descriptors for LPIs

Signed-off-by: Vijaya Kumar K 
---
v8: - Use gic_nr_irq_ids() instead of nr_lpis
v6: - Add separate patch for irq_pending structures
- renamed and moved is_domain_lpi to vgic
- Updated __irq_to_domain
---
 xen/arch/arm/gic-v3-its.c |4 
 xen/arch/arm/irq.c|   37 -
 xen/include/asm-arm/irq.h |1 +
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index e495d4d..1dcfc39 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -1496,6 +1496,10 @@ int __init its_init(struct rdist_prop *rdists)
 its_alloc_lpi_tables();
 its_lpi_init(rdists->id_bits);
 
+/* Allocate irq descriptors for LPIs */
+if ( init_lpi() )
+return -ENOMEM;
+
 its = list_first_entry(_nodes, struct its_node, entry);
 /*
  * As per vITS design spec, Xen exposes only one virtual ITS per domain.
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 3baac5d..e4c6019 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -31,6 +31,8 @@
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
 
+static irq_desc_t *irq_desc_lpi;
+
 /* Describe an IRQ assigned to a guest */
 struct irq_guest
 {
@@ -61,7 +63,15 @@ static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], 
local_irq_desc);
 irq_desc_t *__irq_to_desc(int irq)
 {
 if (irq < NR_LOCAL_IRQS) return _cpu(local_irq_desc)[irq];
-return _desc[irq-NR_LOCAL_IRQS];
+else if ( gic_is_lpi(irq) )
+{
+ASSERT(irq_desc_lpi != NULL);
+return _desc_lpi[irq - FIRST_GIC_LPI];
+}
+else
+return _desc[irq - NR_LOCAL_IRQS];
+
+return NULL;
 }
 
 int __init arch_init_one_irq_desc(struct irq_desc *desc)
@@ -111,6 +121,31 @@ static int init_local_irq_data(void)
 return 0;
 }
 
+int init_lpi(void)
+{
+struct irq_desc *desc;
+unsigned int i, nr_lpis;
+
+nr_lpis = gic_nr_irq_ids() - FIRST_GIC_LPI;
+ASSERT(nr_lpis >= 0);
+
+/* Allocate LPI irq descriptors */
+irq_desc_lpi = xzalloc_array(struct irq_desc, nr_lpis);
+if ( !irq_desc_lpi )
+return -ENOMEM;
+
+for ( i = 0; i < nr_lpis; i++ )
+{
+   desc = _desc_lpi[i];
+   init_one_irq_desc(desc);
+   desc->irq = FIRST_GIC_LPI + i;
+   desc->arch.type = DT_IRQ_TYPE_EDGE_BOTH;
+   desc->action = NULL;
+}
+
+return 0;
+}
+
 void __init init_IRQ(void)
 {
 int irq;
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 4bb9464..323f6c0 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -65,6 +65,7 @@ int platform_get_irq(const struct dt_device_node *device, int 
index);
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
 void irq_set_msi_desc(struct irq_desc *desc, struct msi_desc *msi);
 struct msi_desc *irq_get_msi_desc(struct irq_desc *desc);
+int init_lpi(void);
 
 #endif /* _ASM_HW_IRQ_H */
 /*
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 03/28] xen/arm: Set nr_cpu_ids to available number of cpus

[vijayak]

From: Vijaya Kumar K 

nr_cpu_ids for arm platforms is incorrectly set to NR_CPUS
irrespective of the number of cpus supported by platform.

Signed-off-by: Vijaya Kumar K 
Reviewed-by: Julien Grall 
---
v6: - Updated nr_cpu_ids in setup.c instead of creating
  a helper function
---
 xen/arch/arm/setup.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e95759d..fac74d4 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -771,6 +771,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 smp_init_cpus();
 cpus = smp_get_max_cpus();
+printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
+nr_cpu_ids = cpus;
 
 init_xen_time();
 
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 24/28] xen/arm: ITS: Route LPIs

[vijayak]

From: Vijaya Kumar K 

Allocate and initialize irq descriptor for LPIs and
route LPIs to guest

For LPIs deactivation is not required. Hence
GICH_LR.HW is not required to set.

Signed-off-by: Vijaya Kumar K 
---
v7: - Subtract 8192 from irq number to index to lpi property
  table to read priority
v6: - Moved ITS specific code from irq.c to vgic.c and
  introduced vgic_vcpu_raise_lpi()
- Renamed gicv3_set_properties to gicv3_set_irq_properties
- Always Inject LPI to vcpu0
- Changed route_lpi_to_guest definition
---
 xen/arch/arm/gic-v3-its.c |   17 ++-
 xen/arch/arm/gic-v3.c |   16 --
 xen/arch/arm/gic.c|   32 +++-
 xen/arch/arm/irq.c|  112 ++---
 xen/arch/arm/vgic-v3-its.c|2 +-
 xen/arch/arm/vgic.c   |  103 +++--
 xen/include/asm-arm/gic-its.h |3 ++
 xen/include/asm-arm/gic.h |8 ++-
 xen/include/asm-arm/irq.h |2 +
 xen/include/asm-arm/vgic.h|3 ++
 10 files changed, 276 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 1dcfc39..cbf517a 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -475,6 +475,21 @@ static void its_flush_and_invalidate_prop(struct irq_desc 
*desc, const u8 *cfg)
 its_send_inv(its_dev, vid);
 }
 
+void its_set_lpi_properties(struct irq_desc *desc,
+const cpumask_t *cpu_mask,
+unsigned int priority)
+{
+unsigned long flags;
+u8 *cfg;
+
+spin_lock_irqsave(_lock, flags);
+cfg = gic_rdists->prop_page + desc->irq - FIRST_GIC_LPI;
+*cfg = (*cfg & 3) | (priority & LPI_PRIORITY_MASK) ;
+
+its_flush_and_invalidate_prop(desc, cfg);
+spin_unlock_irqrestore(_lock, flags);
+}
+
 static void its_set_lpi_state(struct irq_desc *desc, int enable)
 {
 u8 *cfg;
@@ -920,7 +935,7 @@ int its_assign_device(struct domain *d, u32 vdevid, u32 
pdevid)
 for ( i = 0; i < pdev->event_map.nr_lpis; i++ )
 {
 plpi = its_get_plpi(pdev, i);
-/* TODO: Route lpi */
+route_lpi_to_guest(d, plpi, "LPI");
 }
 
 return 0;
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 73b2708..47e6b8a 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -498,9 +498,9 @@ static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
  MPIDR_AFFINITY_LEVEL(mpidr, 0));
 }
 
-static void gicv3_set_irq_properties(struct irq_desc *desc,
- const cpumask_t *cpu_mask,
- unsigned int priority)
+static void gicv3_set_line_properties(struct irq_desc *desc,
+  const cpumask_t *cpu_mask,
+  unsigned int priority)
 {
 uint32_t cfg, actual, edgebit;
 uint64_t affinity;
@@ -564,6 +564,16 @@ static int gicv3_dist_supports_lpis(void)
 return readl_relaxed(GICD + GICD_TYPER) & GICD_TYPER_LPIS_SUPPORTED;
 }
 
+static void gicv3_set_irq_properties(struct irq_desc *desc,
+ const cpumask_t *cpu_mask,
+ unsigned int priority)
+{
+if ( gic_is_lpi(desc->irq) )
+its_set_lpi_properties(desc, cpu_mask, priority);
+else
+gicv3_set_line_properties(desc, cpu_mask, priority);
+}
+
 static void __init gicv3_dist_init(void)
 {
 uint32_t type;
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index d54bba9..ca115c3 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -72,6 +72,13 @@ bool_t gic_is_lpi(unsigned int irq)
 return (irq >= FIRST_GIC_LPI && irq < gic_nr_irq_ids());
 }
 
+/* Validates PPIs/SGIs/SPIs/LPIs supported */
+bool_t gic_is_valid_irq(unsigned int irq)
+{
+return (irq < gic_hw_ops->info->nr_lines || gic_is_lpi(irq));
+}
+
+/* Returns number of PPIs/SGIs/SPIs supported */
 unsigned int gic_number_lines(void)
 {
 return gic_hw_ops->info->nr_lines;
@@ -124,7 +131,8 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const 
cpumask_t *cpu_mask,
   unsigned int priority)
 {
 ASSERT(priority <= 0xff); /* Only 8 bits of priority */
-ASSERT(desc->irq < gic_number_lines());/* Can't route interrupts that 
don't exist */
+/* Can't route interrupts that don't exist */
+ASSERT(gic_is_valid_irq(desc->irq));
 ASSERT(test_bit(_IRQ_DISABLED, >status));
 ASSERT(spin_is_locked(>lock));
 
@@ -173,6 +181,26 @@ out:
 return res;
 }
 
+int gic_route_lpi_to_guest(struct domain *d, struct irq_desc *desc,
+   unsigned int priority)
+{
+ASSERT(spin_is_locked(>lock));
+
+desc->handler = gic_hw_ops->gic_get_guest_irq_type(desc->irq);
+set_bit(_IRQ_GUEST, >status);
+
+/* Set cpumask to current processor */
+gic_set_irq_properties(desc, 

[Xen-devel] [PATCH v8 20/28] xen/arm: ITS: Add virtual ITS availability check helper

[vijayak]

From: Vijaya Kumar K 

Introduce vgic_is_lpi_supported() helper function
to know virtual ITS availability for a domain

Signed-off-by: Vijaya Kumar K 
---
v8: - Dropped its_enabled field
v7: - its_enabled field is added to vgic structure
---
 xen/arch/arm/vgic.c|5 +
 xen/include/asm-arm/vgic.h |1 +
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index f813931..2d89b7c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -62,6 +62,11 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned 
int irq)
 return vgic_get_rank(v, rank);
 }
 
+bool_t vgic_is_lpi_supported(struct domain *d)
+{
+return (d->arch.vgic.nr_lpis != 0);
+}
+
 static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
 INIT_LIST_HEAD(>inflight);
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index f13adfd..35d06b8 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -311,6 +311,7 @@ extern int vgic_emulate(struct cpu_user_regs *regs, union 
hsr hsr);
 extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n);
 extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n);
 extern void register_vgic_ops(struct domain *d, const struct vgic_ops *ops);
+extern bool_t vgic_is_lpi_supported(struct domain *d);
 int vgic_v2_init(struct domain *d);
 int vgic_v3_init(struct domain *d);
 
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 04/28] xen/arm: Rename NR_IRQs and vgic_num_irqs helper function

[vijayak]

From: Vijaya Kumar K 

NR_IRQS represents the number of lines (i.e SGIs, PPIs and SPIs).
With the introduction of LPIs, NR_IRQs is renamed to NR_ITLINES.
Similarly vgic_num_irqs() is renamed as vgic_num_irq_lines().

Signed-off-by: Vijaya Kumar K 
Reviewed-by: Julien Grall 
---
v7: - Renamed NR_LINE_IRQS as NR_ITLINES and vgic_num_line_irqs()
  as vgic_num_irq_lines()
---
 xen/arch/arm/gic.c |2 +-
 xen/arch/arm/irq.c |   10 +-
 xen/arch/arm/vgic-v3.c |2 +-
 xen/arch/arm/vgic.c|   10 +-
 xen/include/asm-arm/irq.h  |9 +
 xen/include/asm-arm/vgic.h |2 +-
 6 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 0b3f634..4b46a71 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -140,7 +140,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 ASSERT(spin_is_locked(>lock));
 /* Caller has already checked that the IRQ is an SPI */
 ASSERT(virq >= 32);
-ASSERT(virq < vgic_num_irqs(d));
+ASSERT(virq < vgic_num_irq_lines(d));
 
 vgic_lock_rank(v_target, rank, flags);
 
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index d409abb..b722737 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -55,7 +55,7 @@ hw_irq_controller no_irq_type = {
 .end = end_none
 };
 
-static irq_desc_t irq_desc[NR_IRQS];
+static irq_desc_t irq_desc[NR_ITLINES];
 static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
 
 irq_desc_t *__irq_to_desc(int irq)
@@ -75,7 +75,7 @@ static int __init init_irq_data(void)
 {
 int irq;
 
-for (irq = NR_LOCAL_IRQS; irq < NR_IRQS; irq++) {
+for (irq = NR_LOCAL_IRQS; irq < NR_ITLINES; irq++) {
 struct irq_desc *desc = irq_to_desc(irq);
 init_one_irq_desc(desc);
 desc->irq = irq;
@@ -407,11 +407,11 @@ int route_irq_to_guest(struct domain *d, unsigned int 
virq,
 unsigned long flags;
 int retval = 0;
 
-if ( virq >= vgic_num_irqs(d) )
+if ( virq >= vgic_num_irq_lines(d) )
 {
 printk(XENLOG_G_ERR
"the vIRQ number %u is too high for domain %u (max = %u)\n",
-   irq, d->domain_id, vgic_num_irqs(d));
+   irq, d->domain_id, vgic_num_irq_lines(d));
 return -EINVAL;
 }
 
@@ -523,7 +523,7 @@ int release_guest_irq(struct domain *d, unsigned int virq)
 int ret;
 
 /* Only SPIs are supported */
-if ( virq < NR_LOCAL_IRQS || virq >= vgic_num_irqs(d) )
+if ( virq < NR_LOCAL_IRQS || virq >= vgic_num_irq_lines(d) )
 return -EINVAL;
 
 p = spi_to_pending(d, virq);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index dba2449..70cf67e 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -909,7 +909,7 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
  * Number of interrupt identifier bits supported by the GIC
  * Stream Protocol Interface
  */
-unsigned int irq_bits = get_count_order(vgic_num_irqs(v->domain));
+unsigned int irq_bits = get_count_order(vgic_num_irq_lines(v->domain));
 /*
  * Number of processors that may be used as interrupt targets when ARE
  * bit is zero. The maximum is 8.
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index ee35683..8cb3b06 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -143,7 +143,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis)
 return ret;
 
 d->arch.vgic.allocated_irqs =
-xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irqs(d)));
+xzalloc_array(unsigned long, BITS_TO_LONGS(vgic_num_irq_lines(d)));
 if ( !d->arch.vgic.allocated_irqs )
 return -ENOMEM;
 
@@ -299,7 +299,7 @@ void arch_move_irqs(struct vcpu *v)
 struct vcpu *v_target;
 int i;
 
-for ( i = 32; i < vgic_num_irqs(d); i++ )
+for ( i = 32; i < vgic_num_irq_lines(d); i++ )
 {
 v_target = vgic_get_target_vcpu(v, i);
 p = irq_to_pending(v_target, i);
@@ -505,7 +505,7 @@ void vgic_vcpu_inject_spi(struct domain *d, unsigned int 
virq)
 struct vcpu *v;
 
 /* the IRQ needs to be an SPI */
-ASSERT(virq >= 32 && virq <= vgic_num_irqs(d));
+ASSERT(virq >= 32 && virq <= vgic_num_irq_lines(d));
 
 v = vgic_get_target_vcpu(d->vcpu[0], virq);
 vgic_vcpu_inject_irq(v, virq);
@@ -527,7 +527,7 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
 
 bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
 {
-if ( virq >= vgic_num_irqs(d) )
+if ( virq >= vgic_num_irq_lines(d) )
 return 0;
 
 return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
@@ -547,7 +547,7 @@ int vgic_allocate_virq(struct domain *d, bool_t spi)
 else
 {
 first = 32;
-end = vgic_num_irqs(d);
+end = 

[Xen-devel] [PATCH v8 09/28] xen/arm: ITS: Introduce gic_is_lpi helper function

[vijayak]

From: Vijaya Kumar K 

Helper function gic_is_lpi() is used to find
if irq is lpi or not. For GICv2 platforms this function
returns number of irq ids which represents only number of line irqs.
For GICv3 platform irq ids are calculated from nr_lpis if
HW supports LPIs

Signed-off-by: Vijaya Kumar K 
CC: Zoltan Kiss 
---
v8: - Move nr_lpis command line option to gic-v3.c.
- nr_lpis is initialized only if ITS is supported.
- Updates doc for nr_lpis command line option.
- Used msi command line option to enable/disable ITS.
v7: - Rename gic_info.nr_id_bits as gic_info.nr_irq_ids
- gic_is_lpi() is common for both ARM64/32
- Introduce global variable nr_lpis from patch #17
- Reset nr_lpis to 0 when HW does not support LPIs
- pass nr_lpis as boot args to Xen. Set minimum to 8192
v6: - Added gic_info.nr_id_bits to hold number of SPI/LPIs
  supported
- Dropped is_lpi() callback
---
 docs/misc/xen-command-line.markdown |7 +
 xen/arch/arm/gic-hip04.c|2 ++
 xen/arch/arm/gic-v2.c   |2 ++
 xen/arch/arm/gic-v3.c   |   49 +++
 xen/arch/arm/gic.c  |   10 +++
 xen/include/asm-arm/gic.h   |5 
 6 files changed, 75 insertions(+)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index d267a04..dcbc838 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1556,3 +1556,10 @@ mode.
 > Default: `true`
 
 Permit use of the `xsave/xrstor` instructions.
+
+### nr_lpis (ARM)
+> `= `
+
+> Default: `8192`
+
+Number of LPIs supported by Xen.
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index a42cf24..9a4091b 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -301,6 +301,8 @@ static void __init hip04gic_dist_init(void)
 
 /* Only 1020 interrupts are supported */
 gicv2_info.nr_lines = min(1020U, nr_lines);
+/* Number of IRQ ids supported */
+gicv2_info.nr_irq_ids = gicv2_info.nr_lines;
 
 /* Turn on the distributor */
 writel_gicd(GICD_CTL_ENABLE, GICD_CTLR);
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 793dca7..915fd63 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -287,6 +287,8 @@ static void __init gicv2_dist_init(void)
 
 /* Only 1020 interrupts are supported */
 gicv2_info.nr_lines = min(1020U, nr_lines);
+/* Number of IRQ ids supported */
+gicv2_info.nr_irq_ids = nr_lines;
 
 /* Turn on the distributor */
 writel_gicd(GICD_CTL_ENABLE, GICD_CTLR);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a8082ab..9a7d99f 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -58,6 +58,33 @@ static struct gic_info gicv3_info;
 /* per-cpu re-distributor base */
 DEFINE_PER_CPU(struct rdist, rdist);
 
+/* Enable/Disable ITS support */
+static bool_t its_enable  = 0;
+
+static void __init parse_its_param(char *s)
+{
+if ( !parse_bool(s) )
+its_enable = 0;
+}
+
+/* 'msi' command line option to enable/disable ITS */
+custom_param("msi", parse_its_param);
+
+/*
+ * Number of LPIs supported by Xen.
+ *
+ * The LPI identifier starts from 8192. Given that the hardware is
+ * providing the number of identifier bits, supporting LPIs requires at
+ * least 14 bits. This will represent 16384 interrupt ID of which 8192
+ * LPIs. So the minimum of LPIs supported when the hardware supports LPIs
+ * is 8192.
+ */
+#define DEFAULT_NR_LPIS8192
+static unsigned int nr_lpis;
+
+/* 'nr_lpis' command line option to specify number of LPIs supported by Xen. */
+integer_param("nr_lpis", nr_lpis);
+
 #define GICD   (gicv3.map_dbase)
 #define GICD_RDIST_BASE(this_cpu(rdist).rbase)
 #define GICD_RDIST_SGI_BASE(GICD_RDIST_BASE + SZ_64K)
@@ -529,6 +556,11 @@ static void gicv3_set_irq_properties(struct irq_desc *desc,
 spin_unlock();
 }
 
+static int gicv3_dist_supports_lpis(void)
+{
+return readl_relaxed(GICD + GICD_TYPER) & GICD_TYPER_LPIS_SUPPORTED;
+}
+
 static void __init gicv3_dist_init(void)
 {
 uint32_t type;
@@ -578,6 +610,23 @@ static void __init gicv3_dist_init(void)
 
 /* Only 1020 interrupts are supported */
 gicv3_info.nr_lines = min(1020U, nr_lines);
+
+/*
+ * Number of IRQ ids supported.
+ * Here we override HW supported number of LPIs and
+ * limit to to LPIs specified in nr_lpis.
+ */
+if ( its_enable && gicv3_dist_supports_lpis() )
+{
+/* Minimum number of lpi supported is 8192 */
+if ( nr_lpis < DEFAULT_NR_LPIS )
+nr_lpis = DEFAULT_NR_LPIS;
+
+gicv3_info.nr_irq_ids = nr_lpis + FIRST_GIC_LPI;
+}
+else
+gicv3_info.nr_irq_ids = gicv3_info.nr_lines;
+
 }
 
 static int gicv3_enable_redist(void)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c

[Xen-devel] [PATCH v8 10/28] xen/arm: ITS: Implement hw_irq_controller for LPIs

[vijayak]

From: Vijaya Kumar K 

Implement hw_irq_controller callbacks required to
handle LPIs.

Signed-off-by: Vijaya Kumar K 
Reviewed-by: Julien Grall 
---
v8: - Removed const before hw_irq_controller for lpis
v7: - Split this patch into two. In this patch implement
  only hw_irq_controller callbacks for LPIs.
v6: - Moved this patch #15 in v5 to patch #9
- Introduce inv command
- Moved msi_desc helper functions to separate
  "xen/arm: ITS: Introduce msi_desc for LPIs"
- Exported LPI hw_irq_controller structure and removed
  helper function to access.
v5: - Fixed review comments
- Exposed gicv3_[host|guest]_irq_end and hook to its
v4: - Implement separate hw_irq_controller for LPIs
- Drop setting LPI affinity
- virq and vid are moved under union
- Introduced inv command handling
- its_device is stored in irq_desc
---
 xen/arch/arm/gic-v3-its.c |  119 +
 xen/arch/arm/gic-v3.c |2 +-
 xen/include/asm-arm/gic_v3_defs.h |2 +
 3 files changed, 122 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index c233950..fa88a75 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -446,6 +446,125 @@ static void its_send_discard(struct its_device *dev, u32 
event)
 its_send_single_command(dev->its, , col);
 }
 
+static void its_flush_and_invalidate_prop(struct irq_desc *desc, const u8 *cfg)
+{
+struct its_device *its_dev = irqdesc_get_its_device(desc);
+u32 vid = irqdesc_get_lpi_event(desc);
+
+ASSERT(vid < its_dev->event_map.nr_lpis);
+
+/*
+ * Make the above write visible to the redistributors.
+ * And yes, we're flushing exactly: One. Single. Byte.
+ * Humpf...
+ */
+if ( gic_rdists->flags & RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING )
+clean_and_invalidate_dcache_va_range(cfg, sizeof(*cfg));
+else
+dsb(ishst);
+
+its_send_inv(its_dev, vid);
+}
+
+static void its_set_lpi_state(struct irq_desc *desc, int enable)
+{
+u8 *cfg;
+
+ASSERT(spin_is_locked(_lock));
+
+cfg = gic_rdists->prop_page + desc->irq - FIRST_GIC_LPI;
+if ( enable )
+*cfg |= LPI_PROP_ENABLED;
+else
+*cfg &= ~LPI_PROP_ENABLED;
+
+its_flush_and_invalidate_prop(desc, cfg);
+}
+
+static void its_irq_enable(struct irq_desc *desc)
+{
+unsigned long flags;
+
+ASSERT(spin_is_locked(>lock));
+
+spin_lock_irqsave(_lock, flags);
+clear_bit(_IRQ_DISABLED, >status);
+dsb(sy);
+its_set_lpi_state(desc, 1);
+spin_unlock_irqrestore(_lock, flags);
+}
+
+static void its_irq_disable(struct irq_desc *desc)
+{
+unsigned long flags;
+
+ASSERT(spin_is_locked(>lock));
+
+spin_lock_irqsave(_lock, flags);
+its_set_lpi_state(desc, 0);
+set_bit(_IRQ_DISABLED, >status);
+spin_unlock_irqrestore(_lock, flags);
+}
+
+static unsigned int its_irq_startup(struct irq_desc *desc)
+{
+its_irq_enable(desc);
+
+return 0;
+}
+
+static void its_irq_shutdown(struct irq_desc *desc)
+{
+its_irq_disable(desc);
+}
+
+static void its_irq_ack(struct irq_desc *desc)
+{
+/* No ACK -- reading IAR has done this for us */
+}
+
+static void its_host_irq_end(struct irq_desc *desc)
+{
+/* Lower the priority */
+gicv3_eoi_irq(desc);
+/* LPIs does not have active state. Do not deactivate */
+}
+
+static void its_guest_irq_end(struct irq_desc *desc)
+{
+gicv3_eoi_irq(desc);
+}
+
+static void its_irq_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+/*TODO: Yet to support */
+printk(XENLOG_G_WARNING "ITS: Setting Affinity of LPI is not supported\n");
+
+return;
+}
+
+hw_irq_controller its_host_lpi_type = {
+.typename = "gic-its",
+.startup  = its_irq_startup,
+.shutdown = its_irq_shutdown,
+.enable   = its_irq_enable,
+.disable  = its_irq_disable,
+.ack  = its_irq_ack,
+.end  = its_host_irq_end,
+.set_affinity = its_irq_set_affinity,
+};
+
+hw_irq_controller its_guest_lpi_type = {
+.typename = "gic-its",
+.startup  = its_irq_startup,
+.shutdown = its_irq_shutdown,
+.enable   = its_irq_enable,
+.disable  = its_irq_disable,
+.ack  = its_irq_ack,
+.end  = its_guest_irq_end,
+.set_affinity = its_irq_set_affinity,
+};
+
 /*
  * How we allocate LPIs:
  *
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 9a7d99f..f7cf4e5 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -467,7 +467,7 @@ static void gicv3_mask_irq(struct irq_desc *irqd)
 gicv3_poke_irq(irqd, GICD_ICENABLER);
 }
 
-static void gicv3_eoi_irq(struct irq_desc *irqd)
+void gicv3_eoi_irq(struct irq_desc *irqd)
 {
 /* Lower the priority */
 WRITE_SYSREG32(irqd->irq, ICC_EOIR1_EL1);
diff --git a/xen/include/asm-arm/gic_v3_defs.h 

[Xen-devel] [PATCH v8 08/28] xen/arm: ITS: Add APIs to add and assign device

[vijayak]

From: Vijaya Kumar K 

Add APIs to add devices to RB-tree, assign and remove
devices to domain.

Signed-off-by: Vijaya Kumar K 
---
v8: - Merged its_free_msi_descs() with its_discard_lpis
- Dropped extra spin_unlock() in its_assign_device()
- Dropped check on device domain to be dom0 in assign_device()
- device is assigned to domain in assign_device() instead
  of add_device() function
- Replaced XENLOG_E_ERR with XENLOG_ERR

v7: - Added check for domain in its_assign_device() to avoid
  assigning device to DomU
- Added comments whereever requested
- Called its_remove_device to remove from rb-tree
  when failed to add device
- Changed dprintk to printk
- Store domain pointer instead of domain id in its_device struct
- Free msi_desc and reset irq_desc when lpis are discarded
- Add function its_free_msi_descs() to free msi_desc
v6: - Moved this patch #19 to patch #8
- Used col_map to store collection id
- Use helper functions to update msi_desc members
v5: - Removed its_detach_device API
- Pass nr_ites as parameter to its_add_device
v4: - Introduced helper to populate its_device struct
- Fixed freeing of its_device memory
- its_device struct holds domain id
---
 xen/arch/arm/gic-v3-its.c |  252 +
 xen/include/asm-arm/gic-its.h |6 +
 2 files changed, 258 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 205b610..c233950 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -145,6 +145,19 @@ static struct its_collection *dev_event_to_col(struct 
its_device *dev,
 return its->collections + dev->event_map.col_map[event];
 }
 
+static struct its_node *its_get_phys_node(struct dt_device_node *dt)
+{
+struct its_node *its;
+
+list_for_each_entry(its, _nodes, entry)
+{
+if ( its->dt_node == dt )
+return its;
+}
+
+return NULL;
+}
+
 /* RB-tree helpers for its_device */
 static struct its_device *its_find_device(u32 devid)
 {
@@ -544,6 +557,245 @@ static void its_lpi_free(struct its_device *dev)
 xfree(dev->event_map.col_map);
 }
 
+static inline u32 its_get_plpi(struct its_device *dev, u32 event)
+{
+return dev->event_map.lpi_base + event;
+}
+
+static void its_discard_lpis(struct its_device *dev, u32 ids)
+{
+u32 i;
+struct irq_desc *desc;
+
+for ( i = 0; i < ids; i++ )
+{
+   its_send_discard(dev, i);
+   desc = irq_to_desc(its_get_plpi(dev, i));
+
+   spin_lock(>lock);
+   irqdesc_set_lpi_event(desc, 0);
+   irqdesc_set_its_device(desc, NULL);
+   /*
+* Here only msi_descs are cleaned.
+* TODO: Clean irq_descs of this pLPIs.
+*/
+   xfree(irq_get_msi_desc(desc));
+   irq_set_msi_desc(desc, NULL);
+   spin_unlock(>lock);
+}
+}
+
+static int its_alloc_device_irq(struct its_device *dev, u32 *hwirq)
+{
+int idx;
+
+idx = find_first_zero_bit(dev->event_map.lpi_map, dev->event_map.nr_lpis);
+if ( idx == dev->event_map.nr_lpis )
+return -ENOSPC;
+
+*hwirq = its_get_plpi(dev, idx);
+set_bit(idx, dev->event_map.lpi_map);
+
+return 0;
+}
+
+static void its_free_device(struct its_device *dev)
+{
+xfree(dev->itt);
+its_lpi_free(dev);
+xfree(dev);
+}
+
+static struct its_device *its_alloc_device(u32 devid, u32 nr_ites,
+   struct dt_device_node *dt_its)
+{
+struct its_device *dev;
+unsigned long *lpi_map;
+int lpi_base, sz;
+u16 *col_map = NULL;
+
+dev = xzalloc(struct its_device);
+if ( dev == NULL )
+return NULL;
+
+dev->its = its_get_phys_node(dt_its);
+if ( dev->its == NULL )
+{
+printk(XENLOG_ERR
+   "ITS: Failed to find ITS node for devid 0x%"PRIx32"\n", devid);
+goto err;
+}
+
+/*
+ * At least one bit of EventID is being used, hence a minimum
+ * of two entries. No, the architecture doesn't let you
+ * express an ITT with a single entry.
+ */
+nr_ites = max(2UL, roundup_pow_of_two(nr_ites));
+sz = nr_ites * dev->its->ite_size;
+sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
+
+dev->itt = xzalloc_bytes(sz);
+if ( !dev->itt )
+goto err;
+
+lpi_map = its_lpi_alloc_chunks(nr_ites, _base);
+if ( !lpi_map )
+goto lpi_err;
+
+col_map = xzalloc_bytes(sizeof(*col_map) * nr_ites);
+if ( !col_map )
+goto col_err;
+
+dev->event_map.lpi_map = lpi_map;
+dev->event_map.lpi_base = lpi_base;
+dev->event_map.col_map = col_map;
+dev->event_map.nr_lpis = nr_ites;
+dev->device_id = devid;
+
+return dev;
+
+col_err:
+its_free_device(dev);
+return NULL;
+lpi_err:
+xfree(dev->itt);
+err:
+xfree(dev);
+
+return NULL;
+}
+
+/* Device assignment */
+int its_add_device(u32 devid, u32 nr_ites, 

[Xen-devel] [PATCH v8 27/28] xen/arm: ITS: Generate ITS node for Dom0

[vijayak]

From: Vijaya Kumar K 

Parse host dt and generate ITS node for Dom0.
ITS node resides inside GIC node so when GIC node
is encountered look for ITS node.

Signed-off-by: Vijaya Kumar K 
---
v7: - Check on return value
v6: - Introduced get_its_phandle in gic_hw_ops
- Removed make_hwdom_its_dt_node callback in gic_hw_ops
- Renamed gic_get_msi_handle() as gic_update_msi_phandle()
- Renamed its_get_phandle to its_update_phandle()
- ITS node generation is wrapped inside GICv3
- Update msi-parent phandle only if msi-parent is ITS
  and find its phandle on demand
v5: - Moved ITS dt node generation to ITS driver
v4: - Generate only one ITS node for Dom0
- Replace msi-parent references to single its phandle
---
 xen/arch/arm/domain_build.c   |   14 +
 xen/arch/arm/gic-v3-its.c |  120 +
 xen/arch/arm/gic-v3.c |   17 +-
 xen/arch/arm/gic.c|8 +++
 xen/include/asm-arm/gic-its.h |2 +
 xen/include/asm-arm/gic.h |5 +-
 6 files changed, 164 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0f0f53e..0c39846 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -468,6 +468,20 @@ static int write_properties(struct domain *d, struct 
kernel_info *kinfo,
 continue;
 }
 
+/*
+ * Replace all msi-parent phandle references to single ITS node
+ * generated for Dom0
+ */
+if ( dt_property_name_is_equal(prop, "msi-parent") )
+{
+DPRINT(" Set msi-parent with ITS phandle (if ITS available)\n");
+res = gic_update_msi_phandle(kinfo->fdt, prop);
+if ( res )
+return res;
+
+continue;
+}
+
 res = fdt_property(kinfo->fdt, prop->name, prop_data, prop_len);
 
 if ( res )
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index cbf517a..2a73b00 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1303,6 +1305,124 @@ static void its_cpu_init_collection(void)
 spin_unlock(_lock);
 }
 
+int its_make_dt_node(const struct domain *d, void *fdt)
+{
+struct its_node *its;
+const struct dt_device_node *node;
+const void *compatible = NULL;
+u32 len;
+__be32 *new_cells, *tmp;
+int res = 0;
+
+/* Will pass only first ITS node info */
+its = list_first_entry(_nodes, struct its_node, entry);
+if ( !its )
+{
+dprintk(XENLOG_ERR, "ITS node not found\n");
+return -FDT_ERR_XEN(ENOENT);
+}
+
+node = its->dt_node;
+
+compatible = dt_get_property(node, "compatible", );
+if ( !compatible )
+{
+dprintk(XENLOG_ERR, "Can't find compatible property for the its 
node\n");
+return -FDT_ERR_XEN(ENOENT);
+}
+
+res = fdt_begin_node(fdt, "gic-its");
+if ( res )
+return res;
+
+res = fdt_property(fdt, "compatible", compatible, len);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "msi-controller", NULL, 0);
+if ( res )
+return res;
+
+len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+
+new_cells = xzalloc_bytes(len);
+if ( new_cells == NULL )
+return -FDT_ERR_XEN(ENOMEM);
+tmp = new_cells;
+
+dt_set_range(, node, its->phys_base, its->phys_size);
+
+res = fdt_property(fdt, "reg", new_cells, len);
+xfree(new_cells);
+if ( res )
+return res;
+
+if ( node->phandle )
+{
+res = fdt_property_cell(fdt, "phandle", node->phandle);
+if ( res )
+return res;
+}
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int its_find_compatible_phandle(fdt32_t msi_parent_phandle)
+{
+struct its_node *its;
+const struct dt_device_node *node;
+fdt32_t phandle;
+
+list_for_each_entry(its, _nodes, entry)
+{
+node = its->dt_node;
+
+if ( node->phandle )
+{
+phandle = cpu_to_fdt32(node->phandle);
+if ( phandle == msi_parent_phandle )
+   return 0;
+}
+}
+
+return -FDT_ERR_XEN(ENOENT);
+}
+
+int its_update_phandle(void *fdt, const struct dt_property *prop)
+{
+struct its_node *its;
+const struct dt_device_node *node;
+fdt32_t phandle, msi_parent_phandle;
+
+memcpy(_parent_phandle, prop->value, sizeof(msi_parent_phandle));
+
+/* chech if msi-parent phandle is ITS */
+if ( its_find_compatible_phandle(msi_parent_phandle) )
+return -FDT_ERR_XEN(ENOENT);
+
+/* Only first ITS node phandle is considered */
+its = list_first_entry(_nodes, struct its_node, entry);
+if ( !its )
+{
+dprintk(XENLOG_ERR, "ITS node not found\n");
+return 

[Xen-devel] [PATCH v8 28/28] xen/arm: ITS: Add pci devices in ThunderX

[vijayak]

From: Vijaya Kumar K 

ITS initialization required for all PCI devices in
ThunderX platform are done by calling from specific
mapping function.

This patch can be reverted once XEN PCI passthrough
framework for arm64 is in available.

For now all the PCI devices are assigned to Dom0

Signed-off-by: Vijaya Kumar K 
Acked-by: Ian Campbell 
---
v7: Calculate size of bdf[] instead of hardcoding count
---
 xen/arch/arm/platforms/Makefile   |1 +
 xen/arch/arm/platforms/thunderx.c |  200 +
 2 files changed, 201 insertions(+)

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index e173fec..d9f98f9 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
+obj-$(CONFIG_ARM_64) += thunderx.o
diff --git a/xen/arch/arm/platforms/thunderx.c 
b/xen/arch/arm/platforms/thunderx.c
new file mode 100644
index 000..1557d98
--- /dev/null
+++ b/xen/arch/arm/platforms/thunderx.c
@@ -0,0 +1,200 @@
+/*
+ * xen/arch/arm/platforms/thunderx.c
+ *
+ * Cavium Thunder specific settings
+ *
+ * Vijaya Kumar K 
+ * Copyright (c) 2015 Cavium Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+struct pci_dev_list 
+{
+   uint32_t seg;
+   uint32_t bus;
+   uint32_t dev;
+   uint32_t func;
+};
+
+static struct pci_dev_list bdf[] =
+{
+{0, 0, 1, 0},
+{0, 0, 2, 0},
+{0, 0, 6, 0},
+{0, 0, 7, 0},
+{0, 0, 10, 0},
+{0, 0, 11, 0},
+{0, 0, 14, 0},
+{0, 0, 15, 0},
+{0, 0, 16, 0},
+{0, 1, 0, 0},
+{0, 1, 0, 1},
+{0, 1, 0, 5},
+{0, 1, 1, 4},
+{0, 1, 9, 0},
+{0, 1, 9, 1},
+{0, 1, 9, 2},
+{0, 1, 9, 3},
+{0, 1, 9, 4},
+{0, 1, 9, 5},
+{0, 1, 10, 0},
+{0, 1, 10, 1},
+{0, 1, 10, 2},
+{0, 1, 10, 3},
+{0, 1, 14, 0},
+{0, 1, 14, 2},
+{0, 1, 14, 4},
+{0, 1, 16, 0},
+{0, 1, 16, 1},
+{0, 2, 0, 0},
+{0, 3, 0, 0},
+{0, 4, 0, 0},
+{1, 0, 1, 0},
+{1, 0, 4, 0},
+{1, 0, 5, 0},
+{1, 0, 6, 0},
+{1, 0, 7, 0},
+{1, 0, 8, 0},
+{1, 0, 9, 0},
+{1, 0, 10, 0},
+{1, 0, 11, 0},
+{2, 0, 1, 0},
+{2, 0, 2, 0},
+{2, 0, 3, 0},
+{2, 1, 0, 0},
+{2, 1, 0, 1},
+{2, 1, 0, 2},
+{2, 1, 0, 3},
+{2, 1, 0, 4},
+{2, 1, 0, 5},
+{2, 1, 0, 6},
+{2, 1, 0, 7},
+{2, 1, 1, 0},
+{2, 1, 1, 1},
+{2, 1, 1, 2},
+{2, 1, 1, 3},
+{2, 1, 1, 4},
+{2, 1, 1, 5},
+{2, 1, 1, 6},
+{2, 1, 1, 7},
+{2, 1, 2, 0},
+{2, 1, 2, 1},
+{2, 1, 2, 2},
+{2, 1, 2, 3},
+{2, 1, 2, 4},
+{2, 1, 2, 5},
+{2, 1, 2, 6},
+{2, 1, 2, 7},
+{2, 1, 3, 0},
+{2, 1, 3, 1},
+{2, 1, 3, 2},
+{2, 1, 3, 3},
+{2, 1, 3, 4},
+{2, 1, 3, 5},
+{2, 1, 3, 6},
+{2, 1, 3, 7},
+{2, 1, 4, 0},
+{2, 1, 4, 1},
+{2, 1, 4, 2},
+{2, 1, 4, 3},
+{2, 1, 4, 4},
+{2, 1, 4, 5},
+{2, 1, 4, 6},
+{2, 1, 4, 7},
+{2, 1, 5, 0},
+{2, 1, 5, 1},
+{2, 1, 5, 2},
+{2, 1, 5, 3},
+{2, 1, 5, 4},
+{2, 1, 5, 5},
+{2, 1, 5, 6},
+{2, 1, 5, 7},
+{2, 1, 6, 0},
+{2, 1, 6, 1},
+{2, 1, 6, 2},
+{2, 1, 6, 3},
+{2, 1, 6, 4},
+{2, 1, 6, 5},
+{2, 1, 6, 6},
+{2, 1, 6, 7},
+{2, 1, 7, 0},
+{2, 1, 7, 1},
+{2, 1, 7, 2},
+{2, 1, 7, 3},
+{2, 1, 7, 4},
+{3, 0, 1, 0},
+};
+
+#define BDF_TO_DEVID(seg, bus, dev, func) (seg << 16 | bus << 8 | dev << 3| 
func)
+
+/* TODO: add and assign devices using PCI framework */
+static int thunderx_specific_mapping(struct domain *d)
+{
+struct dt_device_node *dt_its;
+uint32_t devid, i;
+int res;
+
+static const struct dt_device_match its_device_ids[] __initconst =
+{
+DT_MATCH_GIC_ITS,
+{ /* sentinel */ },
+};
+
+for (dt_its = dt_find_matching_node(NULL, its_device_ids); dt_its;
+   dt_its = dt_find_matching_node(dt_its, its_device_ids))
+{
+break;
+}
+
+if ( dt_its == NULL )
+{
+dprintk(XENLOG_ERR, "ThunderX: ITS node not found to add device\n");
+return 0;
+}
+
+for ( i = 0; i < ARRAY_SIZE(bdf); i++ )
+{
+devid = BDF_TO_DEVID(bdf[i].seg, bdf[i].bus,bdf[i].dev, bdf[i].func);
+

[Xen-devel] [PATCH v8 07/28] xen/arm: ITS: Introduce msi_desc for LPIs

[vijayak]

From: Vijaya Kumar K 

Define msi_desc structure for arm and introduce
helper functions to access msi_desc member variables.

Signed-off-by: Vijaya Kumar K 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/gic-v3-its.c |   28 
 xen/arch/arm/irq.c|   12 
 xen/include/asm-arm/gic-its.h |4 
 xen/include/asm-arm/irq.h |9 +
 4 files changed, 53 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 2716137..205b610 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -109,6 +109,34 @@ static void dump_cmd(const its_cmd_block *cmd)
 static void dump_cmd(const its_cmd_block *cmd) { }
 #endif
 
+void irqdesc_set_lpi_event(struct irq_desc *desc, unsigned id)
+{
+ASSERT(spin_is_locked(>lock));
+
+irq_get_msi_desc(desc)->eventID = id;
+}
+
+unsigned int irqdesc_get_lpi_event(struct irq_desc *desc)
+{
+ASSERT(spin_is_locked(>lock));
+
+return irq_get_msi_desc(desc)->eventID;
+}
+
+struct its_device *irqdesc_get_its_device(struct irq_desc *desc)
+{
+ASSERT(spin_is_locked(>lock));
+
+return irq_get_msi_desc(desc)->dev;
+}
+
+void irqdesc_set_its_device(struct irq_desc *desc, struct its_device *dev)
+{
+ASSERT(spin_is_locked(>lock));
+
+irq_get_msi_desc(desc)->dev = dev;
+}
+
 static struct its_collection *dev_event_to_col(struct its_device *dev,
u32 event)
 {
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index b722737..3baac5d 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -143,6 +143,18 @@ static inline struct domain *irq_get_domain(struct 
irq_desc *desc)
 return irq_get_guest_info(desc)->d;
 }
 
+void irq_set_msi_desc(struct irq_desc *desc, struct msi_desc *msi)
+{
+desc->msi_desc = msi;
+}
+
+struct msi_desc *irq_get_msi_desc(struct irq_desc *desc)
+{
+ASSERT(desc->msi_desc != NULL);
+
+return desc->msi_desc;
+}
+
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask)
 {
 if ( desc != NULL )
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index c950097..70065be 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -277,6 +277,10 @@ struct its_device {
 struct rb_node  node;
 };
 
+void irqdesc_set_lpi_event(struct irq_desc *desc, unsigned id);
+unsigned int irqdesc_get_lpi_event(struct irq_desc *desc);
+struct its_device *irqdesc_get_its_device(struct irq_desc *desc);
+void irqdesc_set_its_device(struct irq_desc *desc, struct its_device *dev);
 int its_init(struct rdist_prop *rdists);
 int its_cpu_init(void);
 
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 9be83b4..4bb9464 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -18,6 +18,13 @@ struct arch_irq_desc {
 unsigned int type;
 };
 
+struct msi_desc {
+#ifdef CONFIG_HAS_GICV3
+unsigned int eventID;
+struct its_device *dev;
+#endif
+};
+
 #define NR_LOCAL_IRQS  32
 /* Number of SGIs + PPIs + SPIs */
 #define NR_ITLINES 1024
@@ -56,6 +63,8 @@ int irq_set_spi_type(unsigned int spi, unsigned int type);
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
+void irq_set_msi_desc(struct irq_desc *desc, struct msi_desc *msi);
+struct msi_desc *irq_get_msi_desc(struct irq_desc *desc);
 
 #endif /* _ASM_HW_IRQ_H */
 /*
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 14/28] xen/arm: ITS: Initialize physical ITS and export lpi support

[vijayak]

From: Vijaya Kumar K 

Initialize physical ITS if HW supports LPIs.

Signed-off-by: Vijaya Kumar K 
---
v8: - Rename lpi_support to its_support.
- Removed its command line parameter.
- Dropped its_enabled global variable.
v7: - Export lpi support information to vgic-v3 driver from gic-v3.
- Drop gic_lpi_supported() helper function
- Add boot param to enable or disable physical ITS
v6: - Updated lpi_supported gic_info member for GICv2 and GICv3
- Introduced helper gic_lpi_supported() and exported
v5: - Made check of its dt node availability before
  setting lpi_supported flag
---
 xen/arch/arm/gic-v3.c |   33 +++--
 xen/arch/arm/vgic-v3.c|5 -
 xen/include/asm-arm/gic_v3_defs.h |1 +
 xen/include/asm-arm/vgic.h|2 +-
 4 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 0e1e2f8..73b2708 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -61,6 +61,8 @@ DEFINE_PER_CPU(struct rdist, rdist);
 
 /* Enable/Disable ITS support */
 static bool_t its_enable  = 0;
+/* Availability of ITS support after successful ITS initialization */
+static bool_t its_enabled = 0;
 
 static void __init parse_its_param(char *s)
 {
@@ -743,6 +745,10 @@ static int gicv3_cpu_init(void)
 if ( gicv3_enable_redist() )
 return -ENODEV;
 
+/* Give LPIs a spin */
+if ( gicv3_dist_supports_lpis() )
+its_cpu_init();
+
 /* Set priority on PPI and SGI interrupts */
 priority = (GIC_PRI_IPI << 24 | GIC_PRI_IPI << 16 | GIC_PRI_IPI << 8 |
 GIC_PRI_IPI);
@@ -1346,8 +1352,11 @@ static int __init gicv3_init(void)
i, r->base, r->base + r->size);
 }
 
-vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
- gicv3.rdist_stride);
+reg = readl_relaxed(GICD + GICD_TYPER);
+
+gicv3.rdist_data.id_bits = ((reg >> GICD_TYPER_ID_BITS_SHIFT) &
+GICD_TYPER_ID_BITS_MASK) + 1;
+
 gicv3_init_v2(node, dbase);
 
 spin_lock_init();
@@ -1355,6 +1364,26 @@ static int __init gicv3_init(void)
 spin_lock();
 
 gicv3_dist_init();
+
+if ( its_enable && gicv3_dist_supports_lpis() )
+{
+/*
+ * LPI support is enabled only if HW supports it and
+ * ITS dt node is available
+ */
+if ( !its_init(_data) )
+its_enabled = 1;
+else
+{
+/* ITS initiazation failed. Reset nr_irq_ids to SPIs */
+gicv3_info.nr_irq_ids = gicv3_info.nr_lines;
+nr_lpis = 0;
+}
+}
+
+vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
+ gicv3.rdist_stride, its_enabled);
+
 res = gicv3_cpu_init();
 gicv3_hyp_init();
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d9b8539..d59f494 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -50,6 +50,8 @@
 
 static struct {
 bool_t enabled;
+/* Check if its supported */
+bool_t its_support;
 /* Distributor interface address */
 paddr_t dbase;
 /* Re-distributor regions */
@@ -61,9 +63,10 @@ static struct {
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride)
+  uint32_t rdist_stride, bool_t its_support)
 {
 vgic_v3_hw.enabled = 1;
+vgic_v3_hw.its_support = its_support;
 vgic_v3_hw.dbase = dbase;
 vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
 vgic_v3_hw.regions = regions;
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 50d2056..f943461 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -45,6 +45,7 @@
 
 /* Additional bits in GICD_TYPER defined by GICv3 */
 #define GICD_TYPER_ID_BITS_SHIFT (19)
+#define GICD_TYPER_ID_BITS_MASK  (0x1f)
 
 #define GICD_TYPER_LPIS_SUPPORTED(1U << 17)
 #define GICD_CTLR_RWP(1UL << 31)
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index e9ec764..f3b7df5 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -341,7 +341,7 @@ struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride);
+  uint32_t rdist_stride, bool_t its_support);
 #endif
 
 #endif /* __ASM_ARM_VGIC_H__ */
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 12/28] xen/arm: ITS: Plumb hw_irq_controller for LPIs

[vijayak]

From: Vijaya Kumar K 

Change callbacks gic_host_irq_type and gic_guest_irq_type
to gic_get_host_irq_type and gic_get_guest_irq_type
in gic_hw_operations, which returns hw_irq_controller based
on irq type (SPI or LPI).

Signed-off-by: Vijaya Kumar K 
CC: Zoltan Kiss 
Reviewed-by: Julien Grall 
---
v8: Dropped helper to get hw_irq_controller
---
 xen/arch/arm/gic-hip04.c  |   14 --
 xen/arch/arm/gic-v2.c |   14 --
 xen/arch/arm/gic-v3.c |   21 +++--
 xen/arch/arm/gic.c|4 ++--
 xen/include/asm-arm/gic-its.h |3 +++
 xen/include/asm-arm/gic.h |4 ++--
 6 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 9a4091b..193849e 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -630,6 +630,16 @@ static hw_irq_controller hip04gic_guest_irq_type = {
 .set_affinity = hip04gic_irq_set_affinity,
 };
 
+static hw_irq_controller *hip04gic_get_host_irq_type(unsigned int irq)
+{
+return _host_irq_type;
+}
+
+static hw_irq_controller *hip04gic_get_guest_irq_type(unsigned int irq)
+{
+return _guest_irq_type;
+}
+
 static int __init hip04gic_init(void)
 {
 int res;
@@ -708,8 +718,8 @@ const static struct gic_hw_operations hip04gic_ops = {
 .save_state  = hip04gic_save_state,
 .restore_state   = hip04gic_restore_state,
 .dump_state  = hip04gic_dump_state,
-.gic_host_irq_type   = _host_irq_type,
-.gic_guest_irq_type  = _guest_irq_type,
+.gic_get_host_irq_type   = hip04gic_get_host_irq_type,
+.gic_get_guest_irq_type  = hip04gic_get_guest_irq_type,
 .eoi_irq = hip04gic_eoi_irq,
 .deactivate_irq  = hip04gic_dir_irq,
 .read_irq= hip04gic_read_irq,
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 915fd63..d8de68e 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -630,6 +630,16 @@ static bool_t gicv2_is_aliased(paddr_t cbase, paddr_t 
csize)
 return ((val_low & 0xfff0fff) == 0x0202043B && val_low == val_high);
 }
 
+static hw_irq_controller *gicv2_get_host_irq_type(unsigned int irq)
+{
+return _host_irq_type;
+}
+
+static hw_irq_controller *gicv2_get_guest_irq_type(unsigned int irq)
+{
+return _guest_irq_type;
+}
+
 static int __init gicv2_init(void)
 {
 int res;
@@ -748,8 +758,8 @@ const static struct gic_hw_operations gicv2_ops = {
 .save_state  = gicv2_save_state,
 .restore_state   = gicv2_restore_state,
 .dump_state  = gicv2_dump_state,
-.gic_host_irq_type   = _host_irq_type,
-.gic_guest_irq_type  = _guest_irq_type,
+.gic_get_host_irq_type   = gicv2_get_host_irq_type,
+.gic_get_guest_irq_type  = gicv2_get_guest_irq_type,
 .eoi_irq = gicv2_eoi_irq,
 .deactivate_irq  = gicv2_dir_irq,
 .read_irq= gicv2_read_irq,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f7cf4e5..45fe624 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* Global state */
@@ -1184,6 +1185,22 @@ static const hw_irq_controller gicv3_guest_irq_type = {
 .set_affinity = gicv3_irq_set_affinity,
 };
 
+static hw_irq_controller *gicv3_get_host_irq_type(unsigned int irq)
+{
+if ( gic_is_lpi(irq) )
+   return _host_lpi_type;
+
+return _host_irq_type;
+}
+
+static hw_irq_controller *gicv3_get_guest_irq_type(unsigned int irq)
+{
+if ( gic_is_lpi(irq) )
+   return _guest_lpi_type;
+
+return _guest_irq_type;
+}
+
 static int __init cmp_rdist(const void *a, const void *b)
 {
 const struct rdist_region *l = a, *r = a;
@@ -1352,8 +1369,8 @@ static const struct gic_hw_operations gicv3_ops = {
 .save_state  = gicv3_save_state,
 .restore_state   = gicv3_restore_state,
 .dump_state  = gicv3_dump_state,
-.gic_host_irq_type   = _host_irq_type,
-.gic_guest_irq_type  = _guest_irq_type,
+.gic_get_host_irq_type   = gicv3_get_host_irq_type,
+.gic_get_guest_irq_type  = gicv3_get_guest_irq_type,
 .eoi_irq = gicv3_eoi_irq,
 .deactivate_irq  = gicv3_dir_irq,
 .read_irq= gicv3_read_irq,
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 0c43a5b..d54bba9 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -128,7 +128,7 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const 
cpumask_t *cpu_mask,
 ASSERT(test_bit(_IRQ_DISABLED, >status));
 ASSERT(spin_is_locked(>lock));
 
-desc->handler = gic_hw_ops->gic_host_irq_type;
+desc->handler = gic_hw_ops->gic_get_host_irq_type(desc->irq);
 
 gic_set_irq_properties(desc, cpu_mask, priority);
 }
@@ -159,7 +159,7 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 

[Xen-devel] [PATCH v8 00/28] Add ITS support

[vijayak]

From: Vijaya Kumar K 

This is based on DraftG version
http://xenbits.xen.org/people/ianc/vits/draftG.pdf

Following major features are supported
 - GICv3 ITS support for arm64 platform
 - Only Dom0 is supported. For DomU pci passthrough feature
   is required.

Major Changes in v8:
 - Rebased to latest staging branch.
 - Tested with kernel 4.2.
 - Introduced new patch xen/arm: Correct GICD_TYPER register definition typos.
 - Dropped xen/arm: Move vgic rank locking inside get_irq_priority.
   This patch is not required with latest code.
 - Used Tasklet to parse LPI property table.

Changes in v7:

 - Rebased to latest staging branch.
 - Compiled all the patches individually for both arm32 and arm64
 - Patch xen-arm-ITS-implement-hw_irq_controller-for-LPIs.patch
   split into two patches.
  - xen-arm-ITS-implement-hw_irq_controller-for-LPIs.patch and
  - xen-arm-ITS-Plumbing-hw_irq_controller-for-LPIs.patch.
 - Moved patch xen-arm-ITS-Add-GITS-registers-emulation.patch
   before vITS compilation.
 - Merged xen-arm-ITS-Enable-virtual-ITS-driver.patch with
   patch xen-arm-ITS-Export-ITS-info-to-Virtual-ITS.patch.
 - Dropped patch xen-arm-ITS-Add-32-bit-access-to-GICR_TYPER.patch.
   This is only minor change. Hence merged with
   xen-arm-ITS-Add-GICR-register-emulation.patch.
 - Dropped patch xen-arm-ITS-Introduce-helper-to-get-number-of-event-.patch
 - Dropped gic_lpi_supported helper function.
 - Changed LPI property table usage and handling.
 - Added support to pass nr_lpis from bootargs.
 - Added support to enable/disable its support from bootargs.
 - Fixed issues around freeing of its_device on error.
 - Introduced vits.h file
 - Dropped xen-dt-Handle-correctly-node-with-interrupt-map-in-d.patch
   from this series as it is already merged.

  Could not share code via Github. Network is very slow.
  Please, let me know if required.

Changes in v6:

 - Rebased to latest staging branch.
 - Compiled all the patches individually for both arm32 and arm64
 - Split the patch "xen/arm: ITS: Allocate irq descriptors for LPIs" into two.
   One for allocating LPI irq_desc and other patch for allocating pending_irq 
desc
   for LPIs
 - Following new patches are introduced
 1) xen/arm: Rename NR_IRQs and vgic_num_irqs helper function
 2) xen/arm: ITS: Introduce msi_desc for LPIs
 3) xen/arm: Move vgic locking inside get_irq_priority callback
 4) xen/arm: ITS: Store LPIs allocated and IRQ ID bits per domain
 5) xen/arm: ITS: Introduce helper to get number of event IDs
 6) xen/arm: ITS: Add virtual ITS availability check helper
 7) xen/arm: ITS: Add 32-bit access to GICR_TYPER)
 8) xen/arm: ITS: Allocate pending_lpi descriptors for LPIs

 - Based on below patch set
 http://lists.xen.org/archives/html/xen-devel/2015-08/msg00168.html

 Some Major TODOs:
   1) Avoid making vits_process_cmd() static in later point of time
   2) How to handle LPI that does not have LPI config table entry.
   3) Enable/disable ITS to Dom0

Changes in v5:
  - Added following new patches
  0001-xen-arm-Return-success-if-dt-node-does-not-have-irq-.patch
  0004-xen-arm-Set-nr_cpu_ids-to-available-number-of-cpus.patch
  0009-xen-arm-ITS-Export-ITS-info-to-Virtual-ITS.patch
  0013-xen-arm-ITS-Implement-gic_is_lpi-helper-function.patch
  - Split patch #12 into two patches #14 & #16
  0014-xen-arm-ITS-Allocate-irq-descriptors-for-LPIs.patch
  0016-xen-arm-ITS-Route-LPIs.patch
  - Introduce new API to route LPI (route_lpi_to_guest() )
  - Moved patch #8 in v4 as patch #19
  - irq_descritors for LPIs are allocated dynamically
  - Removed RB-tree for managing vitual its devices. Will be
introduced when pci-passthrough is implemented
  - its_add_device() api now takes nr_ites and DT its node as parameters
  - some function are kept as non-static when introduced in a patch for
compilation purpose and eventually made static when used.
  - Tested compilation for arm32

Changes in v4:
  - Patch for rate limiting of error message is removed.
  - Patch #4 and #5 in v3 is merged
  - Merged #13 and #16 as one patch
  - hw_irq_controller is implemented for LPIs
  - GITS and GICR emulation for LPIs in separate patches
  - Removed build functions for ITS command in physical ITS driver
  - Added new patch to add and assign devices from platform file
  - Enable compilation of vits and pits driver in separate patch
  - Replace msi-parent property in all pci dt nodes to single
ITS node generated by Xen for Dom0

Vijaya Kumar K (28):
  xen/arm: Add bitmap_find_next_zero_area helper function
  xen: Add log2 functionality
  xen/arm: Set nr_cpu_ids to available number of cpus
  xen/arm: Rename NR_IRQs and vgic_num_irqs helper function
  xen/arm: ITS: Port ITS driver to Xen
  xen/arm: ITS: Add helper functions to manage its_devices
  xen/arm: ITS: Introduce msi_desc for LPIs
  xen/arm: ITS: Add APIs to add and assign device
  xen/arm: ITS: Introduce gic_is_lpi 

[Xen-devel] [PATCH v8 17/28] xen/arm: ITS: Add GITS registers emulation

[vijayak]

From: Vijaya Kumar K 

Emulate GITS* registers

Signed-off-by: Vijaya Kumar K 
---
v8: - Fixed GITS_BASER0 value.
- Added comments for GITS_BASER0.
- Support 32/64 bit access for GITS_BASER0 and GITS_CBASER.
- s/vits->ctrl/vits->ctlr/
- Used VREG{64,32} and VRANGE{64,32} macros
v7: - Fixed wrong usage of vgic_regN* helpers
- coding styles and comments
- GITS_BASER0 is always overwritten with new value every time
  it is updated.
v6: - Removed unrelated code of this patch
- Used vgic_regN_{read,write}
v4: - Removed GICR register emulation
---
 xen/arch/arm/vgic-v3-its.c|  332 +
 xen/arch/arm/vgic-v3.c|9 -
 xen/include/asm-arm/gic-its.h |8 +
 xen/include/asm-arm/gic_v3_defs.h |   14 ++
 xen/include/asm-arm/vgic.h|9 +
 xen/include/asm-arm/vits.h|   27 ++-
 6 files changed, 388 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 22c8a4c..bdcd9f1 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -33,9 +33,27 @@
 #include 
 #include 
 #include 
+#include 
 
 //#define DEBUG_ITS
 
+/* GITS_PIDRn register values for ARM implementations */
+#define GITS_PIDR0_VAL   (0x94)
+#define GITS_PIDR1_VAL   (0xb4)
+#define GITS_PIDR2_VAL   (0x3b)
+#define GITS_PIDR3_VAL   (0x00)
+#define GITS_PIDR4_VAL   (0x04)
+
+/*
+ * GITS_BASER0 is used to allocate memory for the Device table.
+ * Some of the fields GITS_BASER0.Type and GITS_BASER0.Entry_size
+ * are read-only. Initialize GITS_BASER0_Type = 1 ( Device )
+ * and GITS_BASER0.Entry_size = size of vitt structure (vitt)-1.
+ */
+#define GITS_BASER0_INIT_VAL ((1UL << GITS_BASER_TYPE_SHIFT) | \
+  ((sizeof(struct vitt) - 1) <<\
+  GITS_BASER_ENTRY_SIZE_SHIFT))
+
 #ifdef DEBUG_ITS
 # define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
 #else
@@ -505,6 +523,307 @@ err:
 return 0;
 }
 
+static inline void vits_spin_lock(struct vgic_its *vits)
+{
+spin_lock(>lock);
+}
+
+static inline void vits_spin_unlock(struct vgic_its *vits)
+{
+spin_unlock(>lock);
+}
+
+static int vgic_v3_gits_mmio_read(struct vcpu *v, mmio_info_t *info,
+  register_t *r, void *priv)
+{
+struct vgic_its *vits = v->domain->arch.vgic.vits;
+struct hsr_dabt dabt = info->dabt;
+uint64_t val;
+uint32_t gits_reg;
+
+gits_reg = info->gpa - vits->gits_base;
+DPRINTK("%pv: vITS: GITS_MMIO_READ offset 0x%"PRIx32"\n", v, gits_reg);
+
+switch ( gits_reg )
+{
+case VREG32(GITS_CTLR):
+if ( dabt.size != DABT_WORD ) goto bad_width;
+vits_spin_lock(vits);
+*r = vgic_reg32_extract(vits->ctlr, info);
+vits_spin_unlock(vits);
+return 1;
+case VREG32(GITS_IIDR):
+if ( dabt.size != DABT_WORD ) goto bad_width;
+*r = vgic_reg32_extract(GICV3_GICD_IIDR_VAL, info);
+return 1;
+case VREG64(GITS_TYPER):
+/*
+ * GITS_TYPER.HCC = max_vcpus + 1 (max collection supported)
+ * GITS_TYPER.Devbits = HW supported Devbits size
+ * GITS_TYPER.IDbits = HW supported IDbits size
+ * GITS_TYPER.PTA = 0 (Target addresses are linear processor numbers)
+ * GITS_TYPER.ITTSize = Size of struct vitt
+ * GITS_TYPER.Physical = 1
+ */
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+val = ((vits_get_max_collections(v->domain) << GITS_TYPER_HCC_SHIFT ) |
+   ((vits_hw.devID_bits - 1) << GITS_TYPER_DEVBITS_SHIFT) |
+   ((vits_hw.eventID_bits - 1) << GITS_TYPER_IDBITS_SHIFT)|
+   ((sizeof(struct vitt) - 1) << GITS_TYPER_ITT_SIZE_SHIFT)   |
+ GITS_TYPER_PHYSICAL_LPIS);
+*r = vgic_reg64_extract(val, info);
+return 1;
+case 0x0010 ... 0x007c:
+case 0xc000 ... 0xffcc:
+/* Implementation defined -- read ignored */
+goto read_as_zero;
+case VREG64(GITS_CBASER):
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+vits_spin_lock(vits);
+if ( vits->ctlr & GITS_CTLR_ENABLE )
+*r = vgic_reg64_extract(vits->cmd_base, info);
+else
+*r = vgic_reg64_extract(vits->cmd_base_save, info);
+vits_spin_unlock(vits);
+return 1;
+case VREG64(GITS_CWRITER):
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+vits_spin_lock(vits);
+*r = vgic_reg64_extract(vits->cmd_write & 0xfffe0, info);
+vits_spin_unlock(vits);
+return 1;
+case VREG64(GITS_CREADR):
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+*r = vgic_reg64_extract(atomic_read(>cmd_read) & 0xfffe0, info);
+

[Xen-devel] [PATCH v8 11/28] xen/arm: ITS: Enable compilation of physical ITS driver

[vijayak]

From: Vijaya Kumar K 

Enable compilation of pITS driver.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/Makefile |1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9982a93..4970641 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -14,6 +14,7 @@ obj-y += domain_build.o
 obj-y += gic.o gic-v2.o
 obj-$(CONFIG_ARM_32) += gic-hip04.o
 obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-$(CONFIG_HAS_GICV3) += gic-v3-its.o
 obj-y += io.o
 obj-y += irq.o
 obj-y += kernel.o
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 16/28] xen/arm: ITS: Add virtual ITS commands support

[vijayak]

From: Vijaya Kumar K 

Add Virtual ITS command processing support to Virtual ITS driver

Signed-off-by: Vijaya Kumar K 
Reviewed-by: Julien Grall 
---
v8: - Fixed coding styles
v7: - Moved is_valid_collection() declaration to vits.h
- Added check for number of vcpus of a domain in
  vits_domain_init()
- Moved changes in gic-its.h to vits.h
- vits_process_cmd() is made static
- Fixed coding styles
v6: - Updated printk to use correct PRI*
- Moved vits_get_max_collection and is_valid_collection
  helper to this patch
- Added vits_domain_free()
- Few more review comments
v5: - Rename vgic_its_*() to vits_*()
v4: - Use helper function to read from command queue
- Add MOVALL
- Removed check for entry in device in domain RB-tree
---
 xen/arch/arm/vgic-v3-its.c|  432 +
 xen/include/asm-arm/gic-its.h |2 +
 xen/include/asm-arm/vits.h|   14 ++
 3 files changed, 448 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index df54ce5..22c8a4c 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,49 @@
 #include 
 #include 
 
+//#define DEBUG_ITS
+
+#ifdef DEBUG_ITS
+# define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
+#ifdef DEBUG_ITS
+static void dump_cmd(const its_cmd_block *cmd)
+{
+printk("VITS:CMD[0] = 0x%lx CMD[1] = 0x%lx CMD[2] = 0x%lx CMD[3] = 
0x%lx\n",
+   cmd->bits[0], cmd->bits[1], cmd->bits[2], cmd->bits[3]);
+}
+#else
+static void dump_cmd(const its_cmd_block *cmd) { }
+#endif
+
+static inline uint16_t vits_get_max_collections(struct domain *d)
+{
+/*
+ * ITS only supports up to 256 collections without
+ * provisioning external memory. As per vITS design, number of
+ * vCPUS should not exceed max number of collections.
+ */
+ASSERT(d->max_vcpus < 256);
+
+/*
+ * Each collection corresponds to one CPU(vCPU). Collections are
+ * used to move interrupts from one CPU to another. The ITS
+ * mandates to implement N + 1 collections where N is the number of
+ * processor on the platform (i.e max number of VCPUs for a given
+ * guest).
+ * Refer to PRD03-GENC-010745 24 section 4.9.15.
+ */
+return (d->max_vcpus + 1);
+}
+
+bool_t is_valid_collection(struct domain *d, uint16_t col)
+{
+return (col <= vits_get_max_collections(d));
+}
+
 /* ITS device table helper functions */
 static int vits_vdevice_entry(struct domain *d, uint32_t dev_id,
   struct vdevice_table *entry, bool_t set)
@@ -113,6 +157,394 @@ int vits_get_vitt_entry(struct domain *d, uint32_t devid,
 return vits_vitt_entry(d, devid, event, entry, 0);
 }
 
+static int vits_process_sync(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+/* Ignored */
+DPRINTK("%pv: vITS: SYNC: ta 0x%"PRIx32" \n", v, 
virt_cmd->sync.target_addr);
+
+return 0;
+}
+
+static int vits_process_mapvi(struct vcpu *v, struct vgic_its *vits,
+  its_cmd_block *virt_cmd)
+{
+struct vitt entry;
+struct domain *d = v->domain;
+uint16_t vcol_id;
+uint8_t cmd;
+uint32_t vid, dev_id, event;
+
+vcol_id = virt_cmd->mapvi.col;
+vid = virt_cmd->mapvi.phy_id;
+cmd = virt_cmd->mapvi.cmd;
+dev_id = virt_cmd->mapvi.devid;
+
+DPRINTK("%pv: vITS: MAPVI: dev 0x%"PRIx32" vcol %"PRIu16" vid %"PRIu32"\n",
+ v, dev_id, vcol_id, vid);
+
+entry.valid = true;
+entry.vcollection = vcol_id;
+entry.vlpi = vid;
+
+if ( cmd == GITS_CMD_MAPI )
+vits_set_vitt_entry(d, dev_id, vid, );
+else
+{
+event = virt_cmd->mapvi.event;
+vits_set_vitt_entry(d, dev_id, event, );
+}
+
+return 0;
+}
+
+static int vits_process_movi(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+struct vitt entry;
+struct domain *d = v->domain;
+uint32_t dev_id, event;
+uint16_t vcol_id;
+
+vcol_id = virt_cmd->movi.col;
+event = virt_cmd->movi.event;
+dev_id = virt_cmd->movi.devid;
+
+DPRINTK("%pv vITS: MOVI: dev_id 0x%"PRIx32" vcol %"PRIu16" event 
%"PRIu32"\n",
+v, dev_id, vcol_id, event);
+
+if ( vits_get_vitt_entry(d, dev_id, event, ) )
+return -EINVAL;
+
+entry.vcollection = vcol_id;
+
+if ( vits_set_vitt_entry(d, dev_id, event, ) )
+return -EINVAL;
+
+return 0;
+}
+
+static int vits_process_movall(struct vcpu *v, struct vgic_its *vits,
+   its_cmd_block *virt_cmd)
+{
+/* Ignored */
+DPRINTK("%pv: vITS: MOVALL: ta1 0x%"PRIx32" ta2 0x%"PRIx32" \n",
+v, 

[Xen-devel] [PATCH v8 25/28] xen/arm: ITS: Add domain specific ITS initialization

[vijayak]

From: Vijaya Kumar K 

Call domain specific ITS initialization and introduce
callback in vgic for domain free

Signed-off-by: Vijaya Kumar K 
---
v7: - Deprecate use of gic_lpi_supported and instead use
  vgic_v3_hw.lpi_support
v6: - Moved vits_domain_free() out of this patch
---
 xen/arch/arm/vgic-v3.c |   12 
 xen/arch/arm/vgic.c|3 +++
 xen/include/asm-arm/vgic.h |2 ++
 3 files changed, 17 insertions(+)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index aa3c5ed..8c1877f 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1830,6 +1830,11 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.ctlr = VGICD_CTLR_DEFAULT;
 
 spin_lock_init(>arch.vgic.prop_lock);
+if ( is_hardware_domain(d) && vgic_v3_hw.its_support )
+{
+if ( vits_domain_init(d) )
+return -ENODEV;
+}
 
 if ( is_hardware_domain(d) && vgic_v3_hw.its_support )
 {
@@ -1843,9 +1848,16 @@ static int vgic_v3_domain_init(struct domain *d)
 return 0;
 }
 
+void vgic_v3_domain_free(struct domain *d)
+{
+if ( is_hardware_domain(d) && vgic_v3_hw.its_support )
+vits_domain_free(d);
+}
+
 static const struct vgic_ops v3_ops = {
 .vcpu_init   = vgic_v3_vcpu_init,
 .domain_init = vgic_v3_domain_init,
+.domain_free = vgic_v3_domain_free,
 .emulate_sysreg  = vgic_v3_emulate_sysreg,
 /*
  * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index e0ae5a5..c35501b 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -198,6 +198,9 @@ void domain_vgic_free(struct domain *d)
 if ( vgic_is_lpi_supported(d) && d->arch.vgic.prop_page != NULL )
 free_xenheap_pages(d->arch.vgic.prop_page,
get_order_from_bytes(d->arch.vgic.prop_size));
+
+if ( d->arch.vgic.handler->domain_free )
+d->arch.vgic.handler->domain_free(d);
 }
 
 int vcpu_vgic_init(struct vcpu *v)
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 5e194b7..7c1af7d 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -128,6 +128,8 @@ struct vgic_ops {
 int (*vcpu_init)(struct vcpu *v);
 /* Domain specific initialization of vGIC */
 int (*domain_init)(struct domain *d);
+/* Free domain specific resources */
+void (*domain_free)(struct domain *d);
 /* vGIC sysreg emulation */
 int (*emulate_sysreg)(struct cpu_user_regs *regs, union hsr hsr);
 /* Maximum number of vCPU supported */
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 15/28] xen/arm: ITS: Add virtual ITS driver

[vijayak]

From: Vijaya Kumar K 

This patch introduces virtual ITS driver with following
functionality
 - Introduces helper functions to manage device table and
   ITT table in guest memory
 - Helper function to handle virtual ITS devices assigned
   to domain

Signed-off-by: Vijaya Kumar K 
Reviewed-by: Julien Grall 
---
v7: - Moved vits_access_guest_table() from vgic-v3-its.c to vgic.c
  and renamed as vgic_access_guest_memory().
- Renamed entry paramter in vgic_access_guest_memory() to gipa
- Introduced new header file vits.h for vITS and moved vits structures
  from gic-its.h to vits.h
v6: - Exported vits_access_guest_memory() api
v5: - Removed RB tree that manages vitual ITS devices
v4: - Rename functions {find,remove,insert}_vits_* to
  vits_{find,remove,insert}.
- Add common helper function to map and read/write dt
  or vitt table entry.
- Removed unused code
---
 xen/arch/arm/vgic-v3-its.c   |  123 ++
 xen/arch/arm/vgic.c  |   39 ++
 xen/include/asm-arm/domain.h |2 +
 xen/include/asm-arm/vits.h   |   68 +++
 4 files changed, 232 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
new file mode 100644
index 000..df54ce5
--- /dev/null
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2015 Cavium Inc.
+ * Vijaya Kumar K 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* ITS device table helper functions */
+static int vits_vdevice_entry(struct domain *d, uint32_t dev_id,
+  struct vdevice_table *entry, bool_t set)
+{
+uint64_t offset;
+paddr_t dt_entry;
+const struct vgic_its *vits = d->arch.vgic.vits;
+
+BUILD_BUG_ON(sizeof(struct vdevice_table) != 16);
+
+offset = dev_id * sizeof(struct vdevice_table);
+if ( offset > vits->dt_size )
+{
+printk(XENLOG_G_ERR
+   "d%d: vITS: Out of range off 0x%"PRIx64" id 0x%"PRIx32"\n",
+   d->domain_id, offset, dev_id);
+return -EINVAL;
+}
+
+dt_entry = vits->dt_ipa + offset;
+
+return vgic_access_guest_memory(d, dt_entry, entry,
+   sizeof(struct vdevice_table), set);
+}
+
+static int vits_set_vdevice_entry(struct domain *d, uint32_t devid,
+  struct vdevice_table *entry)
+{
+return vits_vdevice_entry(d, devid, entry, 1);
+}
+
+int vits_get_vdevice_entry(struct domain *d, uint32_t devid,
+   struct vdevice_table *entry)
+{
+return vits_vdevice_entry(d, devid, entry, 0);
+}
+
+static int vits_vitt_entry(struct domain *d, uint32_t devid,
+   uint32_t event, struct vitt *entry, bool_t set)
+{
+struct vdevice_table dt_entry;
+paddr_t vitt_entry;
+uint64_t offset;
+
+BUILD_BUG_ON(sizeof(struct vitt) != 8);
+
+if ( vits_get_vdevice_entry(d, devid, _entry) )
+{
+printk(XENLOG_G_ERR
+   "d%d: vITS: Fail to get vdevice for vdevid 0x%"PRIx32"\n",
+   d->domain_id, devid);
+return -EINVAL;
+}
+
+/* dt_entry has been validated in vits_get_vdevice_entry */
+offset = event * sizeof(struct vitt);
+if ( offset > dt_entry.vitt_size )
+{
+printk(XENLOG_G_ERR "d%d: vITS: ITT out of range\n", d->domain_id);
+return -EINVAL;
+}
+
+vitt_entry = dt_entry.vitt_ipa + offset;
+
+return vgic_access_guest_memory(d, vitt_entry, entry,
+   sizeof(struct vitt), set);
+}
+
+static int vits_set_vitt_entry(struct domain *d, uint32_t devid,
+   uint32_t event, struct vitt *entry)
+{
+return vits_vitt_entry(d, devid, event, entry, 1);
+}
+
+int vits_get_vitt_entry(struct domain *d, uint32_t devid,
+uint32_t event, struct vitt *entry)
+{
+return vits_vitt_entry(d, devid, event, entry, 0);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vgic.c 

[Xen-devel] [PATCH v8 19/28] xen/arm: ITS: Store the number of LPIs allocated per domain

[vijayak]

From: Vijaya Kumar K 

Store the number of lpis allocated per domain in vgic structure

Signed-off-by: Vijaya Kumar K 
---
v8: - Updated commit message and added comments
- Removed initialization of vgic.nr_lpis to zero
v7: - Change commit message.
- Store only nr_lpis per domain in vgic structure and drop
  id_bits.
---
 xen/arch/arm/vgic-v3-its.c   |6 ++
 xen/include/asm-arm/domain.h |1 +
 2 files changed, 7 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 36e6385..913b49d 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -860,6 +860,12 @@ int vits_domain_init(struct domain *d)
 ASSERT(is_hardware_domain(d));
 ASSERT(vits_hw.enabled);
 
+/*
+ * HW might support more number of LPIs than specified here for a domain.
+ * Here we limit number of LPIs supported for domain to nr_lpis.
+ */
+d->arch.vgic.nr_lpis = gic_nr_irq_ids() - FIRST_GIC_LPI;
+
 d->arch.vgic.vits = xzalloc(struct vgic_its);
 if ( !d->arch.vgic.vits )
 return -ENOMEM;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 0ac62d9..0904204 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -93,6 +93,7 @@ struct arch_domain
 spinlock_t lock;
 uint32_t ctlr;
 int nr_spis; /* Number of SPIs */
+int nr_lpis; /* Number of LPIs */
 unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
 struct vgic_irq_rank *shared_irqs;
 /*
-- 
1.7.9.5


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v8 13/28] xen/arm: Correct GICD_TYPER register definition typos

[vijayak]

From: Vijaya Kumar K 

GICD_TYPER register definitions are defined as GICD_TYPE.
Rename all GICD_TYPE_* as GICD_TYPER_*

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/gic-hip04.c  |4 ++--
 xen/arch/arm/gic-v2.c |6 +++---
 xen/arch/arm/gic-v3.c |2 +-
 xen/arch/arm/vgic-v2.c|2 +-
 xen/arch/arm/vgic-v3.c|4 ++--
 xen/include/asm-arm/gic.h |8 
 xen/include/asm-arm/gic_v3_defs.h |2 +-
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 193849e..aa57587 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -274,11 +274,11 @@ static void __init hip04gic_dist_init(void)
 writel_gicd(0, GICD_CTLR);
 
 type = readl_gicd(GICD_TYPER);
-nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
+nr_lines = 32 * ((type & GICD_TYPER_LINES) + 1);
 gic_cpus = 16;
 printk("GIC-HIP04: %d lines, %d cpu%s%s (IID %8.8x).\n",
nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
-   (type & GICD_TYPE_SEC) ? ", secure" : "",
+   (type & GICD_TYPER_SEC) ? ", secure" : "",
readl_gicd(GICD_IIDR));
 
 /* Default all global IRQs to level, active low */
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index d8de68e..daa5a76 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -260,11 +260,11 @@ static void __init gicv2_dist_init(void)
 writel_gicd(0, GICD_CTLR);
 
 type = readl_gicd(GICD_TYPER);
-nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
-gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
+nr_lines = 32 * ((type & GICD_TYPER_LINES) + 1);
+gic_cpus = 1 + ((type & GICD_TYPER_CPUS) >> 5);
 printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
-   (type & GICD_TYPE_SEC) ? ", secure" : "",
+   (type & GICD_TYPER_SEC) ? ", secure" : "",
readl_gicd(GICD_IIDR));
 
 /* Default all global IRQs to level, active low */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 45fe624..0e1e2f8 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -574,7 +574,7 @@ static void __init gicv3_dist_init(void)
 writel_relaxed(0, GICD + GICD_CTLR);
 
 type = readl_relaxed(GICD + GICD_TYPER);
-nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
+nr_lines = 32 * ((type & GICD_TYPER_LINES) + 1);
 
 printk("GICv3: %d lines, (IID %8.8x).\n",
nr_lines, readl_relaxed(GICD + GICD_IIDR));
diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index 9adb4a9..1f6619d 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -192,7 +192,7 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 if ( dabt.size != DABT_WORD ) goto bad_width;
 /* No secure world support for guests. */
 vgic_lock(v);
-typer = ((v->domain->max_vcpus - 1) << GICD_TYPE_CPUS_SHIFT)
+typer = ( ((v->domain->max_vcpus - 1) << GICD_TYPER_CPUS_SHIFT) )
 | DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32);
 vgic_unlock(v);
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 70cf67e..d9b8539 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -919,10 +919,10 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 
 if ( dabt.size != DABT_WORD ) goto bad_width;
 /* No secure world support for guests. */
-typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
+typer = ((ncpus - 1) << GICD_TYPER_CPUS_SHIFT |
  DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
 
-typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
+typer |= (irq_bits - 1) << GICD_TYPER_ID_BITS_SHIFT;
 
 *r = vgic_reg32_extract(typer, info);
 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 6b4883a..bdcb189 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -98,10 +98,10 @@
 /* Register bits */
 #define GICD_CTL_ENABLE 0x1
 
-#define GICD_TYPE_LINES 0x01f
-#define GICD_TYPE_CPUS_SHIFT 5
-#define GICD_TYPE_CPUS  0x0e0
-#define GICD_TYPE_SEC   0x400
+#define GICD_TYPER_LINES 0x01f
+#define GICD_TYPER_CPUS_SHIFT 5
+#define GICD_TYPER_CPUS  0x0e0
+#define GICD_TYPER_SEC   0x400
 
 #define GICC_CTL_ENABLE 0x1
 #define GICC_CTL_EOI(0x1 << 9)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index f02e1aae..50d2056 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -44,7 +44,7 @@
 #define GICC_SRE_EL2_ENEL1   (1UL << 3)
 
 /* Additional bits in GICD_TYPER defined by GICv3 */
-#define GICD_TYPE_ID_BITS_SHIFT 19
+#define GICD_TYPER_ID_BITS_SHIFT (19)
 
 #define GICD_TYPER_LPIS_SUPPORTED(1U << 17)
 #define 

Re: [Xen-devel] [PATCH] Xen/PCI: correct notifier used for device removal

[Jan Beulich]

>>> On 01.02.16 at 14:03,  wrote:
> On 01/02/16 12:16, Jan Beulich wrote:
> On 01.02.16 at 13:01,  wrote:
>>> On 01/02/16 11:58, Jan Beulich wrote:
 Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow
 avoiding removal of IOMMU mappings before the driver actually got
 unbound from the device. Naturally we should be using this too.
>>>
>>> Because otherwise...?  What happens if we don't make this change?
>>>
>>> Removing IOMMU mappings for a device when the driver is still bound to
>>> the device looks wrong to me. Surely the device is still active and may
>>> still be performing DMA at this point?
>> 
>> Exactly - you answered your own question (as does the commit
>> referred to).
> 
> I misread, sorry.  I think I will reword this as:
> 
> "Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE to defer the removal
> of IOMMU mappings until the driver has been unbound from the device
> (i.e., until it is guaranteed that there are no outstanding DMA
> transactions).

If you want this, then I think you should add "... or IRQs".

Thanks, Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 04/10] vring: Introduce vring_use_dma_api()

[Michael S. Tsirkin]

On Mon, Feb 01, 2016 at 11:22:03AM +, David Woodhouse wrote:
> On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote:
> > This is a kludge, but no one has come up with a a better idea yet.
> > We'll introduce DMA API support guarded by vring_use_dma_api().
> > Eventually we may be able to return true on more and more systems,
> > and hopefully we can get rid of vring_use_dma_api() entirely some
> > day.
> > 
> > Signed-off-by: Andy Lutomirski 
> > ---
> >  drivers/virtio/virtio_ring.c | 24 
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index e12e385f7ac3..4b8dab4960bb 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -25,6 +25,30 @@
> >  #include 
> >  #include 
> >  
> > +/*
> > + * The interaction between virtio and a possible IOMMU is a mess.
> > + *
> > + * On most systems with virtio, physical addresses match bus addresses,
> > + * and it doesn't particularly matter whether we use the DMI API.
> > + *
> > + * On some sytems, including Xen and any system with a physical device
> > + * that speaks virtio behind a physical IOMMU, we must use the DMA API
> > + * for virtio DMA to work at all.
> > + *
> > + * On other systems, including SPARC and PPC64, virtio-pci devices are
> > + * enumerated as though they are behind an IOMMU, but the virtio host
> > + * ignores the IOMMU, so we must either pretend that the IOMMU isn't
> > + * there or somehow map everything as the identity.
> > + *
> > + * For the time being, we preseve historic behavior and bypass the DMA
> > + * API.
> > + */
> 
> I spot at least three typos in there, FWIW. ('DMI API', 'sytems',
> 'preseve').

Good catch, hopefully will be fixed in v2.

> > +static bool vring_use_dma_api(void)
> > +{
> > +   return false;
> > +}
> > +
> 
> I'd quite like to see this be an explicit opt-out for the known-broken
> platforms. We've listed the SPARC and PPC64 issues. For x86 I need to
> refresh my memory as a prelude to trying to fix it... was the issue
> *just* that Qemu tends to ship with a broken BIOS that misdescribes the
> virtio devices (and any assigned PCI devices) as being behind an IOMMU
> when they're not, in the rare case that Qemu actually exposes its
> partially-implemented virtual IOMMU to the guest?
> 
> Could we have an arch_vring_eschew_dma_api(dev) function which the
> affected architectures could provide (as a prelude to fixing it so that
> the DMA API does the right thing for *itself*)?

I'm fine with this.

> It would be functionally equivalent, but it would help to push the
> workarounds to the right place — rather than entrenching them for ever
> in tricky "OMG we need to audit what all the architectures do... let's
> not touch it!" code.
> 
> -- 
> David WoodhouseOpen Source Technology Centre
> david.woodho...@intel.com  Intel Corporation
> 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

[Jan Beulich]

Ping? (I'd really like to get this resolved, so we don't need to
indefinitely run with non-upstream behavior in our distros.)

Thanks, Jan

>>> On 13.01.16 at 17:15,  wrote:
 On 13.01.16 at 17:00,  wrote:
>> On 13/01/16 15:36, Jan Beulich wrote:
>> On 13.01.16 at 16:25,  wrote:
 On 12/01/16 15:19, Jan Beulich wrote:
 On 12.01.16 at 12:55,  wrote:
>> On 12/01/16 10:08, Jan Beulich wrote:
>>> This went unnoticed until a backport of this to an older Xen got used,
>>> causing migration of guests enabling this VM assist to fail, because
>>> page table pinning there preceeds vCPU context loading, and hence L4
>>> tables get initialized for the wrong mode. Fix this by post-processing
>>> L4 tables when setting the intended VM assist flags for the guest.
>>>
>>> Note that this leaves in place a dependency on vCPU 0 getting its guest
>>> context restored first, but afaict the logic here is not the only thing
>>> depending on that.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -1067,8 +1067,48 @@ int arch_set_info_guest(
>>>  goto out;
>>>  
>>>  if ( v->vcpu_id == 0 )
>>> +{
>>>  d->vm_assist = c(vm_assist);
>>>  
>>> +/*
>>> + * In the restore case we need to deal with L4 pages which got
>>> + * initialized with m2p_strict still clear (and which hence 
>>> lack 
 the
>>> + * correct initial RO_MPT_VIRT_{START,END} L4 entry).
>>> + */
>>> +if ( d != current->domain && VM_ASSIST(d, m2p_strict) &&
>>> + is_pv_domain(d) && !is_pv_32bit_domain(d) &&
>>> + atomic_read(>arch.pv_domain.nr_l4_pages) )
>>> +{
>>> +bool_t done = 0;
>>> +
>>> +spin_lock_recursive(>page_alloc_lock);
>>> +
>>> +for ( i = 0; ; )
>>> +{
>>> +struct page_info *page = 
>>> page_list_remove_head(>page_list);
>>> +
>>> +if ( page_lock(page) )
>>> +{
>>> +if ( (page->u.inuse.type_info & PGT_type_mask) ==
>>> + PGT_l4_page_table )
>>> +done = !fill_ro_mpt(page_to_mfn(page));
>>> +
>>> +page_unlock(page);
>>> +}
>>> +
>>> +page_list_add_tail(page, >page_list);
>>> +
>>> +if ( done || (!(++i & 0xff) && 
>>> hypercall_preempt_check()) )
>>> +break;
>>> +}
>>> +
>>> +spin_unlock_recursive(>page_alloc_lock);
>>> +
>>> +if ( !done )
>>> +return -ERESTART;
>> This is a long loop.  It is preemptible, but will incur a time delay
>> proportional to the size of the domain during the VM downtime. 
>>
>> Could you defer the loop until after %cr3 has set been set up, and only
>> enter the loop if the kernel l4 table is missing the RO mappings?  That
>> way, domains migrated with migration v2 will skip the loop entirely.
> Well, first of all this would be the result only as long as you or
> someone else don't re-think and possibly move pinning ahead of
> context load again.
 A second set_context() will unconditionally hit the loop though.
>>> Right - another argument against making any change to what is
>>> in the patch right now.
>> 
>> If there are any L4 pages, the current code will unconditionally search
>> the pagelist on every entry to the function, even when it has already
>> fixed up the strictness.
>> 
>> A toolstack can enter this functions multiple times for the same vcpu,
>> by resetting the vcpu state inbetween.  How much do we care about this
>> usage?
> 
> If we cared at all, we'd need to insert another similar piece of
> code in the reset path (moving L4s back to m2p-relaxed mode).
> 
> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

[Andrew Cooper]

On 01/02/16 13:20, Jan Beulich wrote:
> Ping? (I'd really like to get this resolved, so we don't need to
> indefinitely run with non-upstream behavior in our distros.)
>
> Thanks, Jan

My remaining issue is whether this loop gets executed by default.

I realise that there is a difference between legacy and v2 migration,
and that v2 migration by default worked.  If that means we managed to
skip this loop in its entirety for v2, then I am far less concerned
about the overhead.

~Andrew


>
 On 13.01.16 at 17:15,  wrote:
> On 13.01.16 at 17:00,  wrote:
>>> On 13/01/16 15:36, Jan Beulich wrote:
>>> On 13.01.16 at 16:25,  wrote:
> On 12/01/16 15:19, Jan Beulich wrote:
> On 12.01.16 at 12:55,  wrote:
>>> On 12/01/16 10:08, Jan Beulich wrote:
 This went unnoticed until a backport of this to an older Xen got used,
 causing migration of guests enabling this VM assist to fail, because
 page table pinning there preceeds vCPU context loading, and hence L4
 tables get initialized for the wrong mode. Fix this by post-processing
 L4 tables when setting the intended VM assist flags for the guest.

 Note that this leaves in place a dependency on vCPU 0 getting its guest
 context restored first, but afaict the logic here is not the only thing
 depending on that.

 Signed-off-by: Jan Beulich 

 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -1067,8 +1067,48 @@ int arch_set_info_guest(
  goto out;
  
  if ( v->vcpu_id == 0 )
 +{
  d->vm_assist = c(vm_assist);
  
 +/*
 + * In the restore case we need to deal with L4 pages which got
 + * initialized with m2p_strict still clear (and which hence 
 lack 
> the
 + * correct initial RO_MPT_VIRT_{START,END} L4 entry).
 + */
 +if ( d != current->domain && VM_ASSIST(d, m2p_strict) &&
 + is_pv_domain(d) && !is_pv_32bit_domain(d) &&
 + atomic_read(>arch.pv_domain.nr_l4_pages) )
 +{
 +bool_t done = 0;
 +
 +spin_lock_recursive(>page_alloc_lock);
 +
 +for ( i = 0; ; )
 +{
 +struct page_info *page = 
 page_list_remove_head(>page_list);
 +
 +if ( page_lock(page) )
 +{
 +if ( (page->u.inuse.type_info & PGT_type_mask) ==
 + PGT_l4_page_table )
 +done = !fill_ro_mpt(page_to_mfn(page));
 +
 +page_unlock(page);
 +}
 +
 +page_list_add_tail(page, >page_list);
 +
 +if ( done || (!(++i & 0xff) && 
 hypercall_preempt_check()) )
 +break;
 +}
 +
 +spin_unlock_recursive(>page_alloc_lock);
 +
 +if ( !done )
 +return -ERESTART;
>>> This is a long loop.  It is preemptible, but will incur a time delay
>>> proportional to the size of the domain during the VM downtime. 
>>>
>>> Could you defer the loop until after %cr3 has set been set up, and only
>>> enter the loop if the kernel l4 table is missing the RO mappings?  That
>>> way, domains migrated with migration v2 will skip the loop entirely.
>> Well, first of all this would be the result only as long as you or
>> someone else don't re-think and possibly move pinning ahead of
>> context load again.
> A second set_context() will unconditionally hit the loop though.
 Right - another argument against making any change to what is
 in the patch right now.
>>> If there are any L4 pages, the current code will unconditionally search
>>> the pagelist on every entry to the function, even when it has already
>>> fixed up the strictness.
>>>
>>> A toolstack can enter this functions multiple times for the same vcpu,
>>> by resetting the vcpu state inbetween.  How much do we care about this
>>> usage?
>> If we cared at all, we'd need to insert another similar piece of
>> code in the reset path (moving L4s back to m2p-relaxed mode).
>>
>> Jan
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
>


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

flight 79587 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79587/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
79450

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxad0b40fa944628d6f30b40266a599b285d70a266
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  207 days
Failing since 59348  2015-07-10 04:24:05 Z  206 days  139 attempts
Testing same since79450  2016-01-30 04:29:49 Z2 days2 attempts


4001 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  

Re: [Xen-devel] Clarifying PVH mode requirements

[Boris Ostrovsky]

On 02/01/2016 05:28 AM, Roger Pau Monné wrote:
IIRC Boris (CCed) added support for 32bit PVH to Linux, so you should 
be able to use either 32 or 64 kernels. Roger. 


This actually never happened for Linux: HVMlite showed up fast enough 
that it didn't make sense anymore to add 32-bit support to Linux 
(especially given that AMD was still not supported).


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] libxl/remus: Move the assert before the info is used. [and 1 more messages]

[Ian Jackson]

Wei Liu writes ("Re: [PATCH 3/4] libxl/remus: Change the assert for info to an 
return"):
> On Tue, Jan 26, 2016 at 04:30:59PM -0500, Konrad Rzeszutek Wilk wrote:
> > The assert(info) is after quite a lot of manipulations
> > on 'info' - which makes the assert pointless because if
> > info was NULL it would have crashed earlier.
> 
> This sounds sensible.

I don't think I agree.

As I wrote in response to a previous version:

Ian Jackson writes ("Re: [PATCH 2/3] libxl/remus: Move the assert
before the info is used."):
> I think the assert should simply be removed.  We don't assert() other
> pointer parameters for non-NULL-ness.
> 
> Certainly turning null pointer bugs into ERROR_INVALID is very
> unfriendly.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Xen/PCI: correct notifier used for device removal

[David Vrabel]

On 01/02/16 12:16, Jan Beulich wrote:
 On 01.02.16 at 13:01,  wrote:
>> On 01/02/16 11:58, Jan Beulich wrote:
>>> Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow
>>> avoiding removal of IOMMU mappings before the driver actually got
>>> unbound from the device. Naturally we should be using this too.
>>
>> Because otherwise...?  What happens if we don't make this change?
>>
>> Removing IOMMU mappings for a device when the driver is still bound to
>> the device looks wrong to me. Surely the device is still active and may
>> still be performing DMA at this point?
> 
> Exactly - you answered your own question (as does the commit
> referred to).

I misread, sorry.  I think I will reword this as:

"Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE to defer the removal
of IOMMU mappings until the driver has been unbound from the device
(i.e., until it is guaranteed that there are no outstanding DMA
transactions).

Naturally we should be using this too."

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Jan Beulich]

>>> On 01.02.16 at 13:49,  wrote:
> On Mon, Feb 01, 2016 at 05:15:16AM -0700, Jan Beulich wrote:
>> >>> On 01.02.16 at 13:02,  wrote:
>> > On Mon, Feb 01, 2016 at 12:52:51AM -0700, Jan Beulich wrote:
>> >> >>> On 30.01.16 at 15:38,  wrote:
>> >> 
>> >> > On 1/30/2016 12:33 AM, Jan Beulich wrote:
>> >> > On 29.01.16 at 11:45,  wrote:
>> >> >>> --- a/xen/arch/x86/hvm/hvm.c
>> >> >>> +++ b/xen/arch/x86/hvm/hvm.c
>> >> >>> @@ -940,6 +940,8 @@ static int 
>> >> >>> hvm_ioreq_server_alloc_rangesets(struct 
>> > hvm_ioreq_server *s,
>> >> >>>   {
>> >> >>>   unsigned int i;
>> >> >>>   int rc;
>> >> >>> +unsigned int max_wp_ram_ranges =
>> >> >>> +
>> >> >>> s->domain->arch.hvm_domain.params[HVM_PARAM_MAX_WP_RAM_RANGES];
>> >> >>
>> >> >> You're still losing the upper 32 bits here. Iirc you agreed to range
>> >> >> check the value before storing into params[]...
>> >> > 
>> >> > Thanks, Jan. :)
>> >> > In this version, the check is added in routine parse_config_data().
>> >> > If option 'max_wp_ram_ranges' is configured with an unreasonable value,
>> >> > the xl will terminate, before calling xc_hvm_param_set(). Does this
>> >> > change meet your requirement? Or maybe did I have some misunderstanding
>> >> > on this issue?
>> >> 
>> >> Checking in the tools is desirable, but the hypervisor shouldn't rely
>> >> on any tool side checking.
>> >> 
>> > 
>> > As in hypervisor needs to sanitise all input from toolstack? I don't
>> > think Xen does that today.
>> 
>> If it doesn't, then that's a bug. Note that in many cases (domctl-s
>> and alike) such bogus trusting in the tool stack behaving correctly
>> is only not a security issue due to XSA-77. Yet with XSA-77 we
>> made quite clear that we shouldn't knowingly allow in further such
>> issues (it'll be hard enough to find and address all existing ones).
> 
> So are you suggesting pulling the check done in toolstack into
> hypervisor?

I think the check in the tools should stay (allowing for a
distinguishable error message to be issued); all I'm saying is
that doing the check in the tools is not enough.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[PGNet Dev]

I'll get the dom0pvh issue logs posted.


http://xenbits.xen.org/docs/unstable/misc/pvh-readme.txt

" ...
To boot 64bit dom0 in PVH mode, add dom0pvh to grub xen command line.
..."

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/pvh.markdown

no mention of dom0pvh ...

http://wiki.xenproject.org/wiki/Linux_PVH

"...
and use on the Xen command line the dom0pvh=1 bootup parameter.
..."

As per my OP, and the 1st document above, I'd added

dom0pvh

to the grub config.

After re-grub2-mkconfig, and reboot -> crash

Changing, per the wiki, to

dom0pvh=1

unfortunately makes no difference. (It'll be useful to get those 3 docs 
consistent in usage).


In any case, here's the serial output with debug on


Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ...Loading 
Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ...


/EndEntire
/EndEntire
file path: file path: 
/ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor

(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1:
/HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 
]]/HD(2,1000,96000,c5cc9661271ee648

,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)
/File(\EFI\OPENSUSE)/File(xen-4.6.0_08-405.efi)/File(xen-4.6.0_08-405.efi)/EndEntire
/EndEntire
Xen 4.6.0_08-405 (c/s ) EFI loader
Using configuration file 'xen-4.6.0_08-405.cfg'
vmlinuz-4.4.0-8.g9f68b90-default: 0x8bf22000-0x8c507000
initrd-4.4.0-8.g9f68b90-default: 0x8afbc000-0x8bf21da8
0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x92a26018
0x:0x03:0x00.0x0: ROM: 0x8000 bytes at 0x92a1d018
0x:0x0f:0x00.0x0: ROM: 0x10800 bytes at 0x929fc018
 __  ___  ______ ___   ___ _  ____  
 \ \/ /___ _ __   | || |  / /_  / _ \   / _ \ ( _ )   | || |  / _ \| ___|
  \  // _ \ '_ \  | || |_| '_ \| | | | | | | |/ _ \ __| || |_| | | |___ \
  /  \  __/ | | | |__   _| (_) | |_| | | |_| | (_) |__|__   _| |_| |___) |
 /_/\_\___|_| |_||_|(_)___(_)___/___\___/ \___/  |_|  \___/|/
   |_|
(XEN) Xen version 4.6.0_08-405 (abu...@suse.de) (gcc (SUSE Linux) 4.8.5) 
debug=n Wed Jan 27 15:23:26 UTC 2016

(XEN) Latest ChangeSet:
(XEN) Console output is synchronous.
(XEN) Bootloader: EFI
(XEN) Command line: dom0pvh=1 dom0_mem=4096M,max:4096M dom0_max_vcpus=1 
dom0_vcpus_pin=true cpuidle=1 cpufreq=xen clocksource=hpet iommu=verbose 
sched=credit vga=gfx-1920x1080x16 com1=1152

(XEN) Video information:
(XEN)  VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 6 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 8000 (reserved)
(XEN)  8000 - 00048000 (usable)
(XEN)  00048000 - 00059000 (reserved)
(XEN)  00059000 - 0005f000 (usable)
(XEN)  0005f000 - 000a (reserved)
(XEN)  0010 - 8d93e000 (usable)
(XEN)  8d93e000 - 8d945000 (ACPI NVS)
(XEN)  8d945000 - 8e25a000 (reserved)
(XEN)  8e25a000 - 8e26 (usable)
(XEN)  8e26 - 8e6a1000 (reserved)
(XEN)  8e6a1000 - 91783000 (usable)
(XEN)  91783000 - 919eb000 (reserved)
(XEN)  919eb000 - 91a1e000 (usable)
(XEN)  91a1e000 - 91a7b000 (reserved)
(XEN)  91a7b000 - 91ae1000 (usable)
(XEN)  91ae1000 - 91b87000 (reserved)
(XEN)  91b87000 - 91bbb000 (usable)
(XEN)  91bbb000 - 91bbc000 (reserved)
(XEN)  91bbc000 - 91bbe000 (usable)
(XEN)  91bbe000 - 91bbf000 (reserved)
(XEN)  91bbf000 - 91bc7000 (usable)
(XEN)  91bc7000 - 91bca000 (reserved)
(XEN)  91bca000 - 91bdd000 (usable)
(XEN)  91bdd000 - 91be8000 (reserved)
(XEN)  91be8000 - 91c69000 (usable)
(XEN)  91c69000 - 91ce6000 (reserved)
(XEN)  91ce6000 - 91d3 (usable)
(XEN)  91d3 - 9208e000 (reserved)
(XEN)  9208e000 - 920d5000 (usable)
(XEN)  920d5000 - 9214b000 (reserved)
(XEN)  9214b000 - 9217e000 (usable)
(XEN)  9217e000 - 92296000 (reserved)
(XEN)  92296000 - 922b5000 (usable)
(XEN)  922b5000 - 92359000 (reserved)
(XEN)  92359000 - 92363000 (usable)
(XEN)  92363000 - 92462000 (reserved)
(XEN)  92462000 - 92467000 (usable)
(XEN)  92467000 - 925b6000 (reserved)
(XEN)  925b6000 - 925b8000 (usable)
(XEN)  925b8000 - 925be000 (reserved)
(XEN)  925be000 - 925c (usable)
(XEN)  925c - 925c6000 (reserved)

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

[osstest service owner]

flight 79786 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79786/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  428607a410e8abfb4bb71195d74cd1157e3d06ae
baseline version:
 xen  e73460f8636160779fbaded71fa739c1c615c9a6

Last test of basis79429  2016-01-29 18:02:20 Z2 days
Testing same since79786  2016-02-01 14:03:08 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Corneliu ZUZU 
  Graeme Gregory 
  Hanjun Guo 
  Ian Campbell 
  Jan Beulich 
  Rafael J. Wysocki 
  Razvan Cojocaru 
  Roger Pau Monné 
  Shannon Zhao 
  Tamas K Lengyel 
  Tim Deegan 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=428607a410e8abfb4bb71195d74cd1157e3d06ae
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
428607a410e8abfb4bb71195d74cd1157e3d06ae
+ branch=xen-unstable-smoke
+ revision=428607a410e8abfb4bb71195d74cd1157e3d06ae
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x428607a410e8abfb4bb71195d74cd1157e3d06ae = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo 

Re: [Xen-devel] [PATCH] MAINTAINERS: cover non-x86 vm_event files

[Tamas K Lengyel]

> Once vm_event.c is added to ARM:
>
> I don't think that's a prerequisite for accepting this patch, is it? (In
> some ways that's the point -- it covers all future ARCH vm_event.c)
>

Oh yea, good point. I just found it odd to list files here that don't (yet)
exist.

Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

[Jan Beulich]

>>> On 01.02.16 at 15:07,  wrote:
> On 01/02/16 13:20, Jan Beulich wrote:
>> Ping? (I'd really like to get this resolved, so we don't need to
>> indefinitely run with non-upstream behavior in our distros.)
> 
> My remaining issue is whether this loop gets executed by default.
> 
> I realise that there is a difference between legacy and v2 migration,
> and that v2 migration by default worked.  If that means we managed to
> skip this loop in its entirety for v2, then I am far less concerned
> about the overhead.

But had been there before: Of course we could skip the loop if
the bit in d->vm_assist doesn't change. But as expressed before,
with you having already indicated that perhaps it would be better
to have v2 migration do the relevant operations in the other (v1)
order, the moment that was actually done the benefit of avoiding
the loop would be gone.

To be clear - if rendering the code dead (which is what you ask
for) until v2 migration happens to get changed is the only way to
get this code in, I will submit a v2 with that extra conditional.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2

[Andrew Cooper]

On 01/02/16 16:28, Jan Beulich wrote:
 On 01.02.16 at 15:07,  wrote:
>> On 01/02/16 13:20, Jan Beulich wrote:
>>> Ping? (I'd really like to get this resolved, so we don't need to
>>> indefinitely run with non-upstream behavior in our distros.)
>> My remaining issue is whether this loop gets executed by default.
>>
>> I realise that there is a difference between legacy and v2 migration,
>> and that v2 migration by default worked.  If that means we managed to
>> skip this loop in its entirety for v2, then I am far less concerned
>> about the overhead.
> But had been there before: Of course we could skip the loop if
> the bit in d->vm_assist doesn't change. But as expressed before,
> with you having already indicated that perhaps it would be better
> to have v2 migration do the relevant operations in the other (v1)
> order, the moment that was actually done the benefit of avoiding
> the loop would be gone.
>
> To be clear - if rendering the code dead (which is what you ask
> for) until v2 migration happens to get changed is the only way to
> get this code in, I will submit a v2 with that extra conditional.

Migration v2 currently loads vcpu context before pinning the pagetables,
which means that the vm_assist should get set up properly, before L4
tables are processed.

It was my understanding that this is the correct way around, and
m2p-strict mode only broke when you backported it to migration v1 systems?

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access and p2m_set_mem_access

[Jan Beulich]

>>> On 01.02.16 at 16:22,  wrote:
> Ian Campbell writes ("Re: [PATCH v2 1/2] altp2m: Merge 
> p2m_set_altp2m_mem_access and p2m_set_mem_access"):
>> It's unfortunate that we've found ourselves here, but I think rather than
>> deprecating the current and adding a new op alongside we should just accept
>> the one-time fragility this time around, add the version field as part of
>> this set of changes and try and remember to include a version number for
>> next time we add a tools only interface. I don't think xenaccess is yet
>> widely used outside of Tamas and the Bitdfender folks, who I would assume
>> can cope with such a change.
> 
> I'm not sure what a separate version number buys us.
> 
>> I could accept changing the op number would make sense, but I don't think
>> we should deprecate the old one (which implies continuing to support it in
>> parallel), if we go this route we should just retire the old number to
>> straight away to return -ENOSYS (or maybe -EACCESS, which is what a version
>> mismatch would have resulted in).
> 
> If we simply want to detect the mismatch that seems like the best
> approach.
> 
> It's not like we're short of memory op values.

Are we not? They need to fit in 6 bits (unless we want to play tricks),
and numbers up to 27 are already in use.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Ian Jackson]

Yu, Zhang writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter 
max_wp_ram_ranges."):
> On 2/2/2016 12:35 AM, Jan Beulich wrote:
>> On 01.02.16 at 17:19,  wrote:
> >> So, we need also validate this param in hvm_allow_set_param,
> >> current although hvm_allow_set_param has not performed any
> >> validation other parameters. We need to do this for the new
> >> ones. Is this understanding correct?
> >
> > Yes.
> >
> >> Another question is: as to the tool stack side, do you think
> >> an error message would suffice? Shouldn't xl be terminated?
> >
> > I have no idea what consistent behavior in such a case would
> > be - I'll defer input on this to the tool stack maintainers.
> 
> Thank you.
> Wei, which one do you prefer?

I think that arrangements should be made for the hypercall failure to
be properly reported to the caller, and properly logged.

I don't think it is desirable to duplicate the sanity check in
xl/libxl/libxc.  That would simply result in there being two limits to
update.

I have to say, though, that the situation with this parameter seems
quite unsatisfactory.  It seems to be a kind of bodge.

The changeable limit is there to prevent excessive resource usage by a
guest.  But the docs suggest that the excessive usage might be
normal.  That sounds like a suboptimal design to me.

For reference, here is the docs proposed in this patch:

  =item 

Re: [Xen-devel] [PATCH v5 04/10] vring: Introduce vring_use_dma_api()

[David Woodhouse]

On Mon, 2016-02-01 at 07:39 -0800, Andy Lutomirski wrote:
> 
> >> Could we have an arch_vring_eschew_dma_api(dev) function which the
> >> affected architectures could provide (as a prelude to fixing it so that
> >> the DMA API does the right thing for *itself*)?
> >
> > I'm fine with this.
> 
> I modified vring_use_dma_api to take a vring_virtqueue* parameter to
> make this easier.
> 
> I'm a bit torn here.  I want to get the mechanism and the Xen part in,
> and there's unlikely to be much debate on those as a matter of
> principle.  I'd also like to flip as many arches over as possible, but
> that could be trickier.  Let me mull over this.

Let's queue the arch_vring_eschew_dma_api() thing up after this first
batch, and not hold it up any further.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCHv7 0/1] x86/ept: reduce translation invalidation impact

[David Vrabel]

This series improves the performance of EPT by further reducing the
impact of the translation invalidations (ept_sync_domain()). By:

a) Deferring invalidations until the p2m write lock is released.

Prior to this change a 16 VCPU guest could not be successfully
migrated on an (admittedly slow) 160 PCPU box because the p2m write
lock was held for such extended periods of time.  This starved the
read lock needed (by the toolstack) to map the domain's memory,
triggering the watchdog.

After this change a 64 VCPU guest could be successfully migrated.

ept_sync_domain() is very expensive because:

a) it uses on_selected_cpus() and the IPI cost can be particularly
   high for a multi-socket machine.

b) on_selected_cpus() is serialized by its own spin lock.

On this particular box, ept_sync_domain() could take ~3-5 ms.

Simply using a fair rw lock was not sufficient to resolve this (but it
was an improvement) as the cost of the ept_sync_domain calls() was
still delaying the read locks enough for the watchdog to trigger (the
toolstack maps a batch of 1024 GFNs at a time, which means trying to
acquire the p2m read lock 1024 times).

Changes in v7:

- Add some more p2m_tlb_flush_sync() calls to PoD.
- More comments.

Changes in v6:

- Fix performance bug in patch #2.
- Improve comments.

Changes in v5:

- Fix PoD by explicitly doing an invalidation before reclaiming zero
  pages.
- Use the same mechanism for dealing with freeing page table pages.
  This isn't a common path and its simpler than the deferred list.

Changes in v4:

- __ept_sync_domain() is a no-op -- invalidates are done before VMENTER.
- initialize ept->invalidate to all ones so the initial invalidate is
  always done.

Changes in v3:

- Drop already applied "x86/ept: remove unnecessary sync after
  resolving misconfigured entries".
- Replaced "mm: don't free pages until mm locks are released" with
  "x86/ept: invalidate guest physical mappings on VMENTER".

Changes in v2:

- Use a per-p2m (not per-CPU) list for page table pages to be freed.
- Hold the write lock while updating the synced_mask.

David


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCHv7] x86/ept: defer the invalidation until the p2m lock is released

[David Vrabel]

Holding the p2m lock while calling ept_sync_domain() is very expensive
since it does a on_selected_cpus() call.  IPIs on many socket machines
can be very slows and on_selected_cpus() is serialized.

It is safe to defer the invalidate until the p2m lock is released
except for two cases:

1. When freeing a page table page (since partial translations may be
   cached).
2. When reclaiming a zero page as part of PoD.

For these cases, add p2m_tlb_flush_sync() calls which will immediately
perform the invalidate before the page is freed or reclaimed.

Signed-off-by: David Vrabel 
---
v7:
- Add some more p2m_tlb_flush_sync() calls to PoD.
- More comments.

v6:
- Move p2m_tlb_flush_sync() to immediately before p2m_free_ptp().  It was
  called all the time otherwise.

v5:
- add p2m_tlb_flush_sync() and call it before freeing pgae table pages
  and reclaiming zeroed pod pages.

v2:
- use per-p2m list for deferred pages.
- update synced_mask while holding write lock.
---
 xen/arch/x86/mm/mm-locks.h | 23 +++
 xen/arch/x86/mm/p2m-ept.c  | 42 ++
 xen/arch/x86/mm/p2m-pod.c  |  4 
 xen/arch/x86/mm/p2m.c  | 19 +++
 xen/include/asm-x86/p2m.h  | 24 
 5 files changed, 96 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 8a40986..2e8747e 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -265,14 +265,21 @@ declare_mm_lock(altp2mlist)
  */
 
 declare_mm_rwlock(altp2m);
-#define p2m_lock(p) \
-{   \
-if ( p2m_is_altp2m(p) ) \
-mm_write_lock(altp2m, &(p)->lock);  \
-else\
-mm_write_lock(p2m, &(p)->lock); \
-}
-#define p2m_unlock(p) mm_write_unlock(&(p)->lock);
+#define p2m_lock(p) \
+do {\
+if ( p2m_is_altp2m(p) ) \
+mm_write_lock(altp2m, &(p)->lock);  \
+else\
+mm_write_lock(p2m, &(p)->lock); \
+(p)->defer_flush++; \
+} while (0)
+#define p2m_unlock(p)   \
+do {\
+if ( --(p)->defer_flush == 0 )  \
+p2m_tlb_flush_and_unlock(p);\
+else\
+mm_write_unlock(&(p)->lock);\
+} while (0)
 #define gfn_lock(p,g,o)   p2m_lock(p)
 #define gfn_unlock(p,g,o) p2m_unlock(p)
 #define p2m_read_lock(p)  mm_read_lock(p2m, &(p)->lock)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index c094320..43c7f1b 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -263,6 +263,7 @@ static void ept_free_entry(struct p2m_domain *p2m, 
ept_entry_t *ept_entry, int l
 unmap_domain_page(epte);
 }
 
+p2m_tlb_flush_sync(p2m);
 p2m_free_ptp(p2m, mfn_to_page(ept_entry->mfn));
 }
 
@@ -1095,15 +1096,10 @@ static void __ept_sync_domain(void *info)
  */
 }
 
-void ept_sync_domain(struct p2m_domain *p2m)
+static void ept_sync_domain_prepare(struct p2m_domain *p2m)
 {
 struct domain *d = p2m->domain;
 struct ept_data *ept = >ept;
-/* Only if using EPT and this domain has some VCPUs to dirty. */
-if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
-return;
-
-ASSERT(local_irq_is_enabled());
 
 if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
 p2m_flush_nestedp2m(d);
@@ -1116,9 +1112,38 @@ void ept_sync_domain(struct p2m_domain *p2m)
  *of an EP4TA reuse is still needed.
  */
 cpumask_setall(ept->invalidate);
+}
+
+static void ept_sync_domain_mask(struct p2m_domain *p2m, const cpumask_t *mask)
+{
+on_selected_cpus(mask, __ept_sync_domain, p2m, 1);
+}
+
+void ept_sync_domain(struct p2m_domain *p2m)
+{
+struct domain *d = p2m->domain;
 
-on_selected_cpus(d->domain_dirty_cpumask,
- __ept_sync_domain, p2m, 1);
+/* Only if using EPT and this domain has some VCPUs to dirty. */
+if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
+return;
+
+ept_sync_domain_prepare(p2m);
+
+if ( p2m->defer_flush )
+{
+p2m->need_flush = 1;
+return;
+}
+
+ept_sync_domain_mask(p2m, d->domain_dirty_cpumask);
+}
+
+static void ept_flush_and_unlock(struct p2m_domain *p2m, bool_t unlock)
+{
+p2m->need_flush = 0;
+if ( unlock )
+mm_write_unlock(>lock);
+ept_sync_domain_mask(p2m, p2m->domain->domain_dirty_cpumask);
 }
 
 static void ept_enable_pml(struct p2m_domain *p2m)
@@ -1169,6 +1194,7 @@ int ept_p2m_init(struct p2m_domain *p2m)
 p2m->change_entry_type_range = ept_change_entry_type_range;
 p2m->memory_type_changed = 

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Yu, Zhang]

On 2/1/2016 11:14 PM, Yu, Zhang wrote:



On 2/1/2016 9:07 PM, Jan Beulich wrote:

On 01.02.16 at 13:49,  wrote:

On Mon, Feb 01, 2016 at 05:15:16AM -0700, Jan Beulich wrote:

On 01.02.16 at 13:02,  wrote:

On Mon, Feb 01, 2016 at 12:52:51AM -0700, Jan Beulich wrote:

On 30.01.16 at 15:38,  wrote:



On 1/30/2016 12:33 AM, Jan Beulich wrote:

On 29.01.16 at 11:45,  wrote:

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -940,6 +940,8 @@ static int
hvm_ioreq_server_alloc_rangesets(struct

hvm_ioreq_server *s,

   {
   unsigned int i;
   int rc;
+unsigned int max_wp_ram_ranges =
+
s->domain->arch.hvm_domain.params[HVM_PARAM_MAX_WP_RAM_RANGES];


You're still losing the upper 32 bits here. Iirc you agreed to
range
check the value before storing into params[]...


Thanks, Jan. :)
In this version, the check is added in routine parse_config_data().
If option 'max_wp_ram_ranges' is configured with an unreasonable
value,
the xl will terminate, before calling xc_hvm_param_set(). Does this
change meet your requirement? Or maybe did I have some
misunderstanding
on this issue?


Checking in the tools is desirable, but the hypervisor shouldn't rely
on any tool side checking.



As in hypervisor needs to sanitise all input from toolstack? I don't
think Xen does that today.


If it doesn't, then that's a bug. Note that in many cases (domctl-s
and alike) such bogus trusting in the tool stack behaving correctly
is only not a security issue due to XSA-77. Yet with XSA-77 we
made quite clear that we shouldn't knowingly allow in further such
issues (it'll be hard enough to find and address all existing ones).


So are you suggesting pulling the check done in toolstack into
hypervisor?


I think the check in the tools should stay (allowing for a
distinguishable error message to be issued); all I'm saying is
that doing the check in the tools is not enough.

Jan



Thank you Jan and Wei. And sorry for the late response.
But I still do not quite understand. :)
If tool stack can guarantee the validity of a parameter,
under which circumstances will hypervisor be threatened?
I'm not familiar with XSA-77, and I'll read it ASAP.

B.R.
Yu


Sorry to bother you, Jan.
After a second thought, I guess one of the security concern
is when some APP is trying to trigger the HVMOP_set_param
directly with some illegal values.
So, we need also validate this param in hvm_allow_set_param,
current although hvm_allow_set_param has not performed any
validation other parameters. We need to do this for the new
ones. Is this understanding correct?
Another question is: as to the tool stack side, do you think
an error message would suffice? Shouldn't xl be terminated?

Thanks
Yu



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Clarifying PVH mode requirements

[Jan Beulich]

>>> On 01.02.16 at 15:54,  wrote:
> On 02/01/2016 08:38 AM, PGNet Dev wrote:
>>
>> Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default 
>> ...Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ...
>>
>> /EndEntire
>> /EndEntire
>> file path: file path: 
>> 
> /ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,
> 1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor
>> (cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1:
>> /HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 
>> ]]/HD(2,1000,96000,c5cc9661271ee648
>> ,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)
>> 
> /File(\EFI\OPENSUSE)/File(xen-4.6.0_08-405.efi)/File(xen-4.6.0_08-405.efi)/EndEnt
> ire 
>>
>> /EndEntire
>> Xen 4.6.0_08-405 (c/s ) EFI loader
>> Using configuration file 'xen-4.6.0_08-405.cfg'
>> vmlinuz-4.4.0-8.g9f68b90-default: 0x8bf22000-0x8c507000
>> initrd-4.4.0-8.g9f68b90-default: 0x8afbc000-0x8bf21da8
>> 0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x92a26018
>> 0x:0x03:0x00.0x0: ROM: 0x8000 bytes at 0x92a1d018
>> 0x:0x0f:0x00.0x0: ROM: 0x10800 bytes at 0x929fc018
>>  __  ___  ______ ___   ___ _  _ ___  
>>  \ \/ /___ _ __   | || |  / /_  / _ \   / _ \ ( _ )   | || |  / _ \| ___|
>>   \  // _ \ '_ \  | || |_| '_ \| | | | | | | |/ _ \ __| || |_| | | |___ \
>>   /  \  __/ | | | |__   _| (_) | |_| | | |_| | (_) |__|__   _| |_| 
>> |___) |
>>  /_/\_\___|_| |_||_|(_)___(_)___/___\___/ \___/  |_| \___/|/
>>|_|
>> (XEN) Xen version 4.6.0_08-405 (abu...@suse.de) (gcc (SUSE Linux) 
>> 4.8.5) debug=n Wed Jan 27 15:23:26 UTC 2016
>>
> 
> 
> 
>> (XEN) [2016-02-01 05:28:29] d0v0 EPT violation 0x1aa (-w-/r-x) gpa 
>> 0x00f100054c mfn 0xf1000 type 5
>> (XEN) [2016-02-01 05:28:29] d0v0 Walking EPT tables for GFN f1000:
>> (XEN) [2016-02-01 05:28:29] d0v0  epte 80084510c107
>> (XEN) [2016-02-01 05:28:29] d0v0  epte 80085b684107
>> (XEN) [2016-02-01 05:28:29] d0v0  epte 800844afb107
>> (XEN) [2016-02-01 05:28:29] d0v0  epte 8050f1000905
>> (XEN) [2016-02-01 05:28:29] d0v0  --- GLA 0xc96a254c
>> (XEN) [2016-02-01 05:28:29] domain_crash called from vmx.c:2685
>> (XEN) [2016-02-01 05:28:29] Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) [2016-02-01 05:28:29] [ Xen-4.6.0_08-405  x86_64 debug=n 
>> Tainted:C ]
>> (XEN) [2016-02-01 05:28:29] CPU:0
>> (XEN) [2016-02-01 05:28:29] RIP: 0010:[]
>> (XEN) [2016-02-01 05:28:29] RFLAGS: 00010246   CONTEXT: hvm 
>> guest (d0v0)
>> (XEN) [2016-02-01 05:28:29] rax: 000d   rbx: 
>> f100054c   rcx: 9e9c4fff
>> (XEN) [2016-02-01 05:28:29] rdx:    rsi: 
>> 0100   rdi: 81eaedc0
>> (XEN) [2016-02-01 05:28:29] rbp: 880164b57908   rsp: 
>> 880164b578d8   r8:  88016d8c7458
>> (XEN) [2016-02-01 05:28:29] r9:  0241   r10: 
>>    r11: 2001
>> (XEN) [2016-02-01 05:28:29] r12: 0020   r13: 
>> 88016453aec0   r14: c96a254c
>> (XEN) [2016-02-01 05:28:29] r15: 880164b57a20   cr0: 
>> 80050033   cr4: 000406b0
>> (XEN) [2016-02-01 05:28:29] cr3: 01e0b000   cr2: 
>> (XEN) [2016-02-01 05:28:29] ds:    es:    fs:    gs:  
>> ss:    cs: 0010
>> (XEN) [2016-02-01 05:28:29] Guest stack trace from rsp=880164b578d8:
>> (XEN) [2016-02-01 05:28:29]   Fault while accessing guest memory.
>> (XEN) [2016-02-01 05:28:29] Hardware Dom0 crashed: rebooting machine 
>> in 5 seconds.
> 
> (+Jan)
> 
> This looks very much like it needs backport of 33c19df9a ("x86/PCI: 
> intercept accesses to RO MMIO from dom0s in HVM containers") from 
> unstable, which fixes PVH regression introduced by 9256f66c1606 
> ("x86/PCI: intercept all PV Dom0 MMCFG writes")

I don't really understand: The former was needed to fix an issue
introduced by the latter, but the latter isn't in 4.6 iirc.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH OSSTEST v1 5/5] mg-show-flight-runvars: recurse on buildjobs upon request

[Ian Campbell]

On Mon, 2016-02-01 at 15:19 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v1 5/5] mg-show-flight-runvars:
> recurse on buildjobs upon request"):
> > By looping over @rows looking for buildjobs runvars and adding those
> > jobs to the output until nothing changes.
> ...
> > Note that synth runvars (if requests) are now sorted in with the
> > regular ones, whereas previously they were listed last. Retaining the
> > old behaviour would be too complex I feel.
> 
> ...
> > -sub collect ($) {
> > -my ($flight) = @_;
> > +$jobcond //= "TRUE";
> ...
> >  my $q = $dbh_tests->prepare
> >     ("SELECT synth, ".(join ',', @cols)." $qfrom ORDER BY synth,
> > name, job");
> 
> You probably want to drop the `synth' from the ORDER here, even if you
> take my suggestion below.  The sort is still a good idea here because
> it ensures that the output is deterministic.

OK

> > +my ($oflight, $ojob) = flight_otherjob($tflight, $row->[2]);
> > +collect($oflight, "job = '$ojob'");
> 
> SQL injection vulnerability, I think.  (There are lots of places
> where jobs are treated this way, but they come from the command line
> or similar, or have been checked against some regexp.)
> 
> I think you should use the $jobcond @jobcondparams pattern.

Indeed. Fixed.

> -foreach my $row (@rows) {
> > +# Sort by runvar name, then (flight+)job.
> > +foreach my $row (sort { $a->[1] cmp $b->[1]//$a->[0] cmp $b->[1] }
> > @rows) {
> 
> If you retain it this way, put spaces round your //.
> 
> But maybe you should use a Schwartzian transform instead.
> 
>    my $xform = sub { [ ($->[1] =~ m/\~$/)." $_->[1] $_->[0]", $_ ]; };

>    foreach my $row (map { $_->[1] } sort { $xform->($a) cmp
>    $xform->($b) etc.

ITIYM:

   foreach my $row (map { $_->[1] }
                    sort { $a->[0] cmp $b->[0] }
                    map { $xform->($_) }
                    @rows) {
        ...
   }

Since doing the xform-> in the sort defeats the purpose (or I don't
properly understand the Schwartzian transform)

> This makes the synth sorting easy too.

Right.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Jan Beulich]

>>> On 01.02.16 at 16:14,  wrote:
> But I still do not quite understand. :)
> If tool stack can guarantee the validity of a parameter,
> under which circumstances will hypervisor be threatened?

At least in disaggregated environments the hypervisor cannot
trust the (parts of the) tool stack(s) living outside of Dom0. But
even without disaggregation in mind it is bad practice to have
the hypervisor assume the tool stack will only pass sane values.
Just at the example of the param you're introducing: You don't
even do the validation in libxc, so any (theoretical) tool stack
no based on xl/libxl would not be guaranteed to pass a sane
value. And even if you moved it into libxc, one could still argue
that there could an even more theoretical tool stack not even
building on top of libxc.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Yu, Zhang]

On 2/2/2016 12:16 AM, Jan Beulich wrote:

On 01.02.16 at 16:14,  wrote:

But I still do not quite understand. :)
If tool stack can guarantee the validity of a parameter,
under which circumstances will hypervisor be threatened?


At least in disaggregated environments the hypervisor cannot
trust the (parts of the) tool stack(s) living outside of Dom0. But
even without disaggregation in mind it is bad practice to have
the hypervisor assume the tool stack will only pass sane values.
Just at the example of the param you're introducing: You don't
even do the validation in libxc, so any (theoretical) tool stack
no based on xl/libxl would not be guaranteed to pass a sane
value. And even if you moved it into libxc, one could still argue
that there could an even more theoretical tool stack not even
building on top of libxc.

Jan



Great. Thank you very much for your patience to explain.
Just sent out another mail about my understanding a moment ago,
seems I partially get it. :)
My vnc connection is too slow, will change the code tomorrow.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel



Yu

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

[Yu, Zhang]

On 2/2/2016 12:35 AM, Jan Beulich wrote:

On 01.02.16 at 17:19,  wrote:

After a second thought, I guess one of the security concern
is when some APP is trying to trigger the HVMOP_set_param
directly with some illegal values.


Not sure what "directly" is supposed to mean here.


I mean with no validation by itself, like libxc...


So, we need also validate this param in hvm_allow_set_param,
current although hvm_allow_set_param has not performed any
validation other parameters. We need to do this for the new
ones. Is this understanding correct?


Yes.


Another question is: as to the tool stack side, do you think
an error message would suffice? Shouldn't xl be terminated?


I have no idea what consistent behavior in such a case would
be - I'll defer input on this to the tool stack maintainers.



Thank you.
Wei, which one do you prefer?

Yu

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel