Xen project Mailing List

jefby

2014-10-13 21:09 GMT+08:00 <xen-devel-request@xxxxxxxxxxxxx>:

Send Xen-devel mailing list submissions to
Â Â Â Â xen-devel@xxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
Â Â Â Â http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel
or, via email, send a message with subject or body 'help' to
Â Â Â Â xen-devel-request@xxxxxxxxxxxxx

You can reach the person managing the list at
Â Â Â Â xen-devel-owner@xxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-devel digest..."

Today's Topics:

Â Â1. [PATCH v2 0/2] Xen: Use ioreq-server API (Paul Durrant)
Â Â2. [PATCH v2 1/2] Add PCI bus listener interface (Paul Durrant)
Â Â3. Re: [PATCH v4 3/7] [RFC] arm/arm64: introduceÂ Â Âis_dma_coherent
Â Â Â (Will Deacon)
Â Â4. Error building exynos5.c with debug ?= n (Tamas K Lengyel)
Â Â5. Re: [PATCH v13 for-xen-4.5 07/21] x86/VPMU: Handle APIC_LVTPC
Â Â Â accesses (Jan Beulich)
Â Â6. Re: [PATCH FOR-4.5] xen: arm64: Handle memory banks which are
Â Â Â not 1GB aligned (Julien Grall)

----------------------------------------------------------------------

Message: 1
Date: Mon, 13 Oct 2014 13:52:45 +0100
From: Paul Durrant <paul.durrant@xxxxxxxxxx>
To: <qemu-devel@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH v2 0/2] Xen: Use ioreq-server API
Message-ID:
Â Â Â Â <1413204767-39317-1-git-send-email-paul.durrant@xxxxxxxxxx>
Content-Type: text/plain

This patch series is v2 of what was the single patch "Xen: Use
the ioreq-server API when available". The code that adds the
PCI bus listener is now in patch #1 of this series and the
remainder of the changes, in patch #2, have been re-worked to
constrain the #ifdefing to xen_common.h, as requested by
Stefano.

------------------------------

Message: 2
Date: Mon, 13 Oct 2014 13:52:46 +0100
From: Paul Durrant <paul.durrant@xxxxxxxxxx>
To: <qemu-devel@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
Cc: Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx>,Â ÂThomas Huth
Â Â Â Â <thuth@xxxxxxxxxxxxxxxxxx>,Â Â Â"Michael S. Tsirkin" <mst@xxxxxxxxxx>,
Â Â Â Â Christian Borntraeger <borntraeger@xxxxxxxxxx>, Paul Durrant
Â Â Â Â <paul.durrant@xxxxxxxxxx>,Â Â Â Paolo Bonzini <pbonzini@xxxxxxxxxx>,
Â Â Â Â Andreas Faerber <afaerber@xxxxxxx>
Subject: [Xen-devel] [PATCH v2 1/2] Add PCI bus listener interface
Message-ID:
Â Â Â Â <1413204767-39317-2-git-send-email-paul.durrant@xxxxxxxxxx>
Content-Type: text/plain

The Xen ioreq-server API, introduced in Xen 4.5, requires that PCI device
models explicitly register with Xen for config space accesses. This patch
adds a PCI bus listener interface which can be used by the Xen interface
code to monitor PCI buses for arrival and departure of devices.

Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
Cc: Michael S. Tsirkin <mst@xxxxxxxxxx>
Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Cc: Andreas Faerber <afaerber@xxxxxxx>
Cc: Thomas Huth <thuth@xxxxxxxxxxxxxxxxxx>
Cc: Peter Crosthwaite <peter.crosthwaite@xxxxxxxxxx>
Cc: Christian Borntraeger <borntraeger@xxxxxxxxxx>
---
Âhw/pci/pci.cÂ Â Â Â Â Â |Â Â65 +++++++++++++++++++++++++++++++++++++++++++++++
Âinclude/hw/pci/pci.hÂ Â |Â Â 9 +++++++
Âinclude/qemu/typedefs.h |Â Â 1 +
Â3 files changed, 75 insertions(+)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 6ce75aa..53c955d 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -122,6 +122,66 @@ static uint16_t pci_default_sub_device_id = PCI_SUBDEVICE_ID_QEMU;

Âstatic QLIST_HEAD(, PCIHostState) pci_host_bridges;

+static QTAILQ_HEAD(pci_listeners, PCIListener) pci_listeners
+Â Â = QTAILQ_HEAD_INITIALIZER(pci_listeners);
+
+enum ListenerDirection { Forward, Reverse };
+
+#define PCI_LISTENER_CALL(_callback, _direction, _args...)Â Â Â \
+Â Â do {Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
+Â Â Â Â PCIListener *_listener;Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
+Â Â Â Â switch (_direction) {Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â case Forward:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â QTAILQ_FOREACH(_listener, &pci_listeners, link) {Â Â\
+Â Â Â Â Â Â Â Â if (_listener->_callback) {Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â Â Â Â Â _listener->_callback(_listener, ##_args);Â Â\
+Â Â Â Â Â Â Â Â }Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â }Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â break;Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
+Â Â Â Â case Reverse:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â QTAILQ_FOREACH_REVERSE(_listener, &pci_listeners,Â Â\
+Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âpci_listeners, link) {Â Â Â Â\
+Â Â Â Â Â Â Â Â if (_listener->_callback) {Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â Â Â Â Â _listener->_callback(_listener, ##_args);Â Â\
+Â Â Â Â Â Â Â Â }Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â }Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â Â Â Â Â break;Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
+Â Â Â Â default:Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
+Â Â Â Â Â Â abort();Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
+Â Â Â Â }Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
+Â Â } while (0)
+
+static int pci_listener_add(DeviceState *dev, void *opaque)
+{
+Â Â if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
+Â Â Â Â PCIDevice *pci_dev = PCI_DEVICE(dev);
+
+Â Â Â Â PCI_LISTENER_CALL(device_add, Forward, pci_dev);
+Â Â }
+
+Â Â return 0;
+}
+
+void pci_listener_register(PCIListener *listener)
+{
+Â Â PCIHostState *host;
+
+Â Â QTAILQ_INSERT_TAIL(&pci_listeners, listener, link);
+
+Â Â QLIST_FOREACH(host, &pci_host_bridges, next) {
+Â Â Â Â PCIBus *bus = host->bus;
+
+Â Â Â Â qbus_walk_children(&bus->qbus, NULL, NULL, pci_listener_add,
+Â Â Â Â Â Â Â Â Â Â Â Â Â ÂNULL, NULL);
+Â Â }
+}
+
+void pci_listener_unregister(PCIListener *listener)
+{
+Â Â QTAILQ_REMOVE(&pci_listeners, listener, link);
+}
+
Âstatic int pci_bar(PCIDevice *d, int reg)
Â{
Â Â Âuint8_t type;
@@ -795,6 +855,8 @@ static void pci_config_free(PCIDevice *pci_dev)

Âstatic void do_pci_unregister_device(PCIDevice *pci_dev)
Â{
+Â Â PCI_LISTENER_CALL(device_del, Reverse, pci_dev);
+
Â Â Âpci_dev->bus->devices[pci_dev->devfn] = NULL;
Â Â Âpci_config_free(pci_dev);

@@ -878,6 +940,9 @@ static PCIDevice *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
Â Â Âpci_dev->config_write = config_write;
Â Â Âbus->devices[devfn] = pci_dev;
Â Â Âpci_dev->version_id = 2; /* Current pci device vmstate version */
+
+Â Â PCI_LISTENER_CALL(device_add, Forward, pci_dev);
+
Â Â Âreturn pci_dev;
Â}

diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index c352c7b..6c21b37 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -303,6 +303,15 @@ struct PCIDevice {
Â Â ÂMSIVectorPollNotifier msix_vector_poll_notifier;
Â};

+struct PCIListener {
+Â Â void (*device_add)(PCIListener *listener, PCIDevice *pci_dev);
+Â Â void (*device_del)(PCIListener *listener, PCIDevice *pci_dev);
+Â Â QTAILQ_ENTRY(PCIListener) link;
+};
+
+void pci_listener_register(PCIListener *listener);
+void pci_listener_unregister(PCIListener *listener);
+
Âvoid pci_register_bar(PCIDevice *pci_dev, int region_num,
Â Â Â Â Â Â Â Â Â Â Â Âuint8_t attr, MemoryRegion *memory);
Âvoid pci_register_vga(PCIDevice *pci_dev, MemoryRegion *mem,
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 04df51b..2b974c6 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -54,6 +54,7 @@ typedef struct PCIHostState PCIHostState;
Âtypedef struct PCIExpressHost PCIExpressHost;
Âtypedef struct PCIBus PCIBus;
Âtypedef struct PCIDevice PCIDevice;
+typedef struct PCIListener PCIListener;
Âtypedef struct PCIExpressDevice PCIExpressDevice;
Âtypedef struct PCIBridge PCIBridge;
Âtypedef struct PCIEAERMsg PCIEAERMsg;
--
1.7.10.4

------------------------------

Message: 3
Date: Mon, 13 Oct 2014 13:57:25 +0100
From: Will Deacon <will.deacon@xxxxxxx>
To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>,
Â Â Â Â "linux@xxxxxxxxxxxxxxxx" <linux@xxxxxxxxxxxxxxxx>,
Â Â Â Â "Ian.Campbell@xxxxxxxxxx" <Ian.Campbell@xxxxxxxxxx>,Â Â Catalin Marinas
Â Â Â Â <Catalin.Marinas@xxxxxxx>,Â Â Â "linux-kernel@xxxxxxxxxxxxxxx"
Â Â Â Â <linux-kernel@xxxxxxxxxxxxxxx>, "david.vrabel@xxxxxxxxxx"
Â Â Â Â <david.vrabel@xxxxxxxxxx>,Â Â Â "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx"
Â Â Â Â <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH v4 3/7] [RFC] arm/arm64: introduce
Â Â Â Â is_dma_coherent
Message-ID: <20141013125725.GA19156@xxxxxxx>
Content-Type: text/plain; charset=us-ascii

On Mon, Oct 13, 2014 at 12:16:14PM +0100, Stefano Stabellini wrote:
> On Fri, 10 Oct 2014, Stefano Stabellini wrote:
> > On Fri, 10 Oct 2014, Will Deacon wrote:
> > > On Fri, Oct 10, 2014 at 12:51:44PM +0100, Stefano Stabellini wrote:
> > > > Introduce a function to check whether a device is dma coherent.
> > > >
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> > > > CC: linux@xxxxxxxxxxxxxxxx
> > > > CC: catalin.marinas@xxxxxxx
> > > > CC: will.deacon@xxxxxxx
> > > > CC: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> > > > ---
> > > >Â arch/arm/include/asm/dma-mapping.hÂ Â|Â Â 6 ++++++
> > > >Â arch/arm64/include/asm/dma-mapping.h |Â Â 5 +++++
> > > >Â 2 files changed, 11 insertions(+)
> > > >
> > > > diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> > > > index c45b61a..bededbb 100644
> > > > --- a/arch/arm/include/asm/dma-mapping.h
> > > > +++ b/arch/arm/include/asm/dma-mapping.h
> > > > @@ -126,6 +126,12 @@ static inline int set_arch_dma_coherent_ops(struct device *dev)
> > > >Â Â Â Â Âset_dma_ops(dev, &arm_coherent_dma_ops);
> > > >Â Â Â Â Âreturn 0;
> > > >Â }
> > > > +
> > > > +static inline bool is_dma_coherent(struct device *dev)
> > > > +{
> > > > +Â Â return (__generic_dma_ops(dev) == &arm_coherent_dma_ops);
> > > > +}
> > >
> > > Hmm, what about the IOMMU ops?
> >
> > Maybe I should check __generic_dma_ops(dev) != &arm_dma_ops?
> > Do you have any better suggestions?
>
> ping?

Without any clear idea about why this is needed or how it's used, I don't
have any better ideas.

Will

------------------------------

Message: 4
Date: Mon, 13 Oct 2014 14:59:39 +0200
From: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
To: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
Subject: [Xen-devel] Error building exynos5.c with debug ?= n
Message-ID:
Â Â Â Â <CAErYnsgZb1Kyu1=Zcsifde69EHqt-GrMTtc2_zEuqEMJ3nPLYQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

When attempting to build the latest xen-unstable from git with debug ?= n
set in Config.mk I get the following error message:

make -f /root/xen/xen/Rules.mk -C platforms built_in.o
make[5]: Entering directory `/root/xen/xen/arch/arm/platforms'
gcc -O2 -fomit-frame-pointer -marm -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefsÂ Â-DNDEBUG
-I/root/xen/xen/include -fno-stack-protector -fno-exceptions
-Wnested-externs -msoft-float -mcpu=cortex-a15
-DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-builtin -fno-common -Werror
-Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
/root/xen/xen/include/xen/config.h -nostdinc -DHAS_PASSTHROUGH
-DHAS_DEVICE_TREE -DHAS_PDX -MMD -MF .vexpress.o.d -c vexpress.c -o
vexpress.o
gcc -O2 -fomit-frame-pointer -marm -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefsÂ Â-DNDEBUG
-I/root/xen/xen/include -fno-stack-protector -fno-exceptions
-Wnested-externs -msoft-float -mcpu=cortex-a15
-DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-builtin -fno-common -Werror
-Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
/root/xen/xen/include/xen/config.h -nostdinc -DHAS_PASSTHROUGH
-DHAS_DEVICE_TREE -DHAS_PDX -MMD -MF .brcm.o.d -c brcm.c -o brcm.o
gcc -O2 -fomit-frame-pointer -marm -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefsÂ Â-DNDEBUG
-I/root/xen/xen/include -fno-stack-protector -fno-exceptions
-Wnested-externs -msoft-float -mcpu=cortex-a15
-DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-builtin -fno-common -Werror
-Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
/root/xen/xen/include/xen/config.h -nostdinc -DHAS_PASSTHROUGH
-DHAS_DEVICE_TREE -DHAS_PDX -MMD -MF .exynos5.o.d -c exynos5.c -o exynos5.o
{standard input}: Assembler messages:
{standard input}:481: Error: .err encountered
{standard input}:482: Error: .err encountered
{standard input}:483: Error: .err encountered
make[5]: *** [exynos5.o] Error 1
make[5]: Leaving directory `/root/xen/xen/arch/arm/platforms'

It compiles fine with debug ?= y.

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xen.org/archives/html/xen-devel/attachments/20141013/5a681d4e/attachment.html>

------------------------------

Message: 5
Date: Mon, 13 Oct 2014 14:02:08 +0100
From: "Jan Beulich" <JBeulich@xxxxxxxx>
To: "Boris Ostrovsky" <boris.ostrovsky@xxxxxxxxxx>
Cc: kevin.tian@xxxxxxxxx, keir@xxxxxxx, suravee.suthikulpanit@xxxxxxx,
Â Â Â Â andrew.cooper3@xxxxxxxxxx, tim@xxxxxxx, dietmar.hahn@xxxxxxxxxxxxxx,
Â Â Â Â xen-devel@xxxxxxxxxxxxx,Â Â Â Â Aravind.Gopalakrishnan@xxxxxxx,
Â Â Â Â jun.nakajima@xxxxxxxxx, dgdegra@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH v13 for-xen-4.5 07/21] x86/VPMU:
Â Â Â Â Handle APIC_LVTPC accesses
Message-ID: <543BE970020000780003E4BD@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

>>> On 03.10.14 at 23:40, <boris.ostrovsky@xxxxxxxxxx> wrote:
> @@ -706,10 +693,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs *regs)
>Â Â Â Â Â Â Â return 0;
>Â Â Â }
>
> -Â Â /* HW sets the MASK bit when performance counter interrupt occurs*/
> -Â Â vpmu->hw_lapic_lvtpc = apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED;
> -Â Â apic_write_around(APIC_LVTPC, vpmu->hw_lapic_lvtpc);

So why is simply deleting this correct? The comment makes pretty
clear why it was being done here. All I could see being valid without
further explanation is the removal of the middle of the three lines.

Jan

------------------------------

Message: 6
Date: Mon, 13 Oct 2014 14:09:10 +0100
From: Julien Grall <julien.grall@xxxxxxxxxx>
To: Ian Campbell <ian.campbell@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx
Cc: Roy Franz <roy.franz@xxxxxxxxxx>, tim@xxxxxxx,Â Â Â Vijay Kilari
Â Â Â Â <vijay.kilari@xxxxxxxxx>,Â Â Â ÂSuravee Suthikulanit
Â Â Â Â <suravee.suthikulpanit@xxxxxxx>,Â Â Â Â stefano.stabellini@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH FOR-4.5] xen: arm64: Handle memory
Â Â Â Â banks which are not 1GB aligned
Message-ID: <543BCEF6.80800@xxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

Hi Ian,

On 10/10/2014 03:43 PM, Ian Campbell wrote:
> The code in the arm64 version of setup_xenheap_mappings was making
> some very confused attempts to handle this but was bogus.
>
> As well as adjusting the mapping to start on a 1GB boundary we also
> need to account for the offset between the start of the mapping and
> the actual start of the heap when converting between page pointers,
> virtual addresses and machine addresses.
>
> I preferred to do this by explicitly accounting for the offset rather
> than adding an offset to the frametable because that approach could
> potentially waste a large amount of frametable (up to just less than
> 1GB worth) but also because of issues with converting mfns from
> outside the regions considered for pdx initialisation (which are not
> 1GB aligned) back and forth.
>
> We already have an idea of the distinction between the start of the
> direct map and the start of the xenheap in the difference between
> DIRECTMAP_VIRT_START and XENHEAP_VIRT_START. Until now these were the
> same thing, but now we change XENHEAP_VIRT_START to point to the
> actual start of heap not the mapping. Surprisingly there was only one
> place which was using the conceptually wrong value.
>
> Also change xenheap_virt_end to a vaddr_t for consistency.
>
> We've been lucky so far that most hardware happens to locate memory
> on a 1GB boundary (we did have reports of a system with memory at a
> half gig boundary which exhibited failures which I didn't manage to
> follow up on successfully). The EFI support has exposed this
> shortcoming by the way it handles reserved memory, which has a
> similar effect to having memory non-1GB aligned.
>
> arm32 does things differently here due to using a small Xen heap and
> a demand mapped domain heap, so isn't affected.
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Cc: Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx>
> Cc: Roy Franz <roy.franz@xxxxxxxxxx>
> Cc: Vijay Kilari <vijay.kilari@xxxxxxxxx>
> ---
> FOR-4.5: This is a bug fix.

Looks good to me:

Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx>

Regards,

--
Julien Grall

------------------------------

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

End of Xen-devel Digest, Vol 116, Issue 297
*******************************************

Re: [Xen-devel] Xen-devel Digest, Vol 116, Issue 297