[PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Jean Guyader]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]


The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the RAM and
mark this region as NVS in the e820. Then we write the
address to the config space (offset 0xfc) so the device
model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/firmware/hvmloader/config.h   |    1 +
 tools/firmware/hvmloader/e820.c     |    8 ++++++++
 tools/firmware/hvmloader/pci.c      |   28 ++++++++++++++++++++++++++++
 tools/firmware/hvmloader/pci_regs.h |    2 ++
 4 files changed, 39 insertions(+), 0 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch --]
[-- Type: text/x-patch; name="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch", Size: 2971 bytes --]

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index d911352..9cac9c1 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -5,6 +5,7 @@
 
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
+extern unsigned long igd_opregion_pgbase;
 
 struct bios_config {
     const char *name;
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 3b50dd0..fd993fe 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -124,6 +124,14 @@ int build_e820_table(struct e820entry *e820,
     e820[nr].type = E820_RAM;
     nr++;
 
+    if ( igd_opregion_pgbase )
+    {
+        e820[nr].addr = igd_opregion_pgbase << PAGE_SHIFT;
+        e820[nr].size = 2 * PAGE_SIZE;
+        e820[nr].type = E820_NVS;
+        nr++;
+    }
+
     /*
      * Explicitly reserve space for special pages.
      * This space starts at RESERVED_MEMBASE an extends to cover various
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 00490f1..13d3822 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -32,6 +32,7 @@ unsigned long pci_mem_start = PCI_MEM_START;
 unsigned long pci_mem_end = PCI_MEM_END;
 
 enum virtual_vga virtual_vga = VGA_none;
+unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
@@ -271,6 +272,33 @@ void pci_setup(void)
         cmd |= PCI_COMMAND_IO;
         pci_writew(vga_devfn, PCI_COMMAND, cmd);
     }
+
+    if ( virtual_vga == VGA_pt )
+    {
+        class     = pci_readw(vga_devfn, PCI_CLASS_DEVICE);
+        vendor_id = pci_readw(vga_devfn, PCI_VENDOR_ID);
+        device_id = pci_readw(vga_devfn, PCI_DEVICE_ID);
+
+        switch ( vendor_id )
+        {
+            case 0x8086: /* PCI_VENDOR_INTEL */
+                for ( i = 0; i < 2; i++ )
+                {
+                    struct xen_add_to_physmap xatp;
+                    xatp.domid = DOMID_SELF;
+                    xatp.space = XENMAPSPACE_gmfn;
+                    xatp.idx   = --hvm_info->low_mem_pgend;
+                    xatp.gpfn  = hvm_info->high_mem_pgend++;
+                    if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
+                        BUG();
+                }
+                igd_opregion_pgbase = hvm_info->low_mem_pgend;
+                pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                        igd_opregion_pgbase << PAGE_SHIFT);
+                break;
+        }
+    }
+
 }
 
 /*
diff --git a/tools/firmware/hvmloader/pci_regs.h b/tools/firmware/hvmloader/pci_regs.h
index f37affe..873255c 100644
--- a/tools/firmware/hvmloader/pci_regs.h
+++ b/tools/firmware/hvmloader/pci_regs.h
@@ -105,6 +105,8 @@
 #define PCI_MIN_GNT  0x3e /* 8 bits */
 #define PCI_MAX_LAT  0x3f /* 8 bits */
 
+#define PCI_INTEL_OPREGION 0xfc /* 32 bits */
+
 #endif /* __HVMLOADER_PCI_REGS_H__ */
 
 /*

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Keir Fraser]

On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:

> 
> The Intel GPU uses a two pages NVS region called OpRegion.
> In order to get full support for the driver in the guest
> we need to map this region.
> 
> This patch reserves 2 pages on the top of the RAM and
> mark this region as NVS in the e820. Then we write the
> address to the config space (offset 0xfc) so the device
> model can map the OpRegion at this address in the guest.

Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.

Is it correct to do this for *all* gfx devices with Intel vendor id?

 -- Keir

> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  tools/firmware/hvmloader/config.h   |    1 +
>  tools/firmware/hvmloader/e820.c     |    8 ++++++++
>  tools/firmware/hvmloader/pci.c      |   28 ++++++++++++++++++++++++++++
>  tools/firmware/hvmloader/pci_regs.h |    2 ++
>  4 files changed, 39 insertions(+), 0 deletions(-)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Jean Guyader]

On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>
>>
>> The Intel GPU uses a two pages NVS region called OpRegion.
>> In order to get full support for the driver in the guest
>> we need to map this region.
>>
>> This patch reserves 2 pages on the top of the RAM and
>> mark this region as NVS in the e820. Then we write the
>> address to the config space (offset 0xfc) so the device
>> model can map the OpRegion at this address in the guest.
>
> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>

Ok, that is handy.

> Is it correct to do this for *all* gfx devices with Intel vendor id?
>

The OpRegion is a Intel GPU specific thing.

Jean

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Jean Guyader]

On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>>
>>>
>>> The Intel GPU uses a two pages NVS region called OpRegion.
>>> In order to get full support for the driver in the guest
>>> we need to map this region.
>>>
>>> This patch reserves 2 pages on the top of the RAM and
>>> mark this region as NVS in the e820. Then we write the
>>> address to the config space (offset 0xfc) so the device
>>> model can map the OpRegion at this address in the guest.
>>
>> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>>
>
> Ok, that is handy.
>
>> Is it correct to do this for *all* gfx devices with Intel vendor id?
>>
>
> The OpRegion is a Intel GPU specific thing.
>

Sorry didn't read carefully the first time, yes I think it's correct
to do that for
all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
a NVS region on the host, but that won't work for stub domain.

Jean

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Jean Guyader]

On 23/11 05:20, Keir Fraser wrote:
> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> 
> > 
> > The Intel GPU uses a two pages NVS region called OpRegion.
> > In order to get full support for the driver in the guest
> > we need to map this region.
> > 
> > This patch reserves 2 pages on the top of the RAM and
> > mark this region as NVS in the e820. Then we write the
> > address to the config space (offset 0xfc) so the device
> > model can map the OpRegion at this address in the guest.
> 
> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> 

I'm calling mem_hole_alloc() in pci_setup (see patch attached),
but that causes an overlap in e820, is that expected?

(XEN) HVM5: E820 table:
(XEN) HVM5:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
(XEN) HVM5:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
(XEN) HVM5:  HOLE: 00000000:000a0000 - 00000000:000e0000
(XEN) HVM5:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
(XEN) HVM5:  [03]: 00000000:00100000 - 00000000:3f800000: RAM
(XEN) HVM5:  HOLE: 00000000:3f800000 - 00000000:feff8000
(XEN) HVM5:  [04]: 00000000:feff8000 - 00000000:feffa000: NVS
(XEN) HVM5:  OVERLAP!!
(XEN) HVM5:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED

Jean

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Keir Fraser]

On 24/11/2011 09:35, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:

> On 23/11 05:20, Keir Fraser wrote:
>> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
>> 
>>> 
>>> The Intel GPU uses a two pages NVS region called OpRegion.
>>> In order to get full support for the driver in the guest
>>> we need to map this region.
>>> 
>>> This patch reserves 2 pages on the top of the RAM and
>>> mark this region as NVS in the e820. Then we write the
>>> address to the config space (offset 0xfc) so the device
>>> model can map the OpRegion at this address in the guest.
>> 
>> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
>> 
> 
> I'm calling mem_hole_alloc() in pci_setup (see patch attached),
> but that causes an overlap in e820, is that expected?

You'll have to adjust your changes to build_e820_table() to split the range
RESERVED_MEMBASE-0x10000000 into two pieces partitioned by your NVS region.

The region starting at RESERVED_MEMBASE comes *before* your NVS region. Then
you add an another reserved region up to 0x1000000 if your NVS region
exists.

 -- Keir

> (XEN) HVM5: E820 table:
> (XEN) HVM5:  [00]: 00000000:00000000 - 00000000:0009e000: RAM
> (XEN) HVM5:  [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
> (XEN) HVM5:  HOLE: 00000000:000a0000 - 00000000:000e0000
> (XEN) HVM5:  [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
> (XEN) HVM5:  [03]: 00000000:00100000 - 00000000:3f800000: RAM
> (XEN) HVM5:  HOLE: 00000000:3f800000 - 00000000:feff8000
> (XEN) HVM5:  [04]: 00000000:feff8000 - 00000000:feffa000: NVS
> (XEN) HVM5:  OVERLAP!!
> (XEN) HVM5:  [05]: 00000000:fc000000 - 00000001:00000000: RESERVED
> 
> Jean

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Stefano Stabellini]

On Wed, 23 Nov 2011, Jean Guyader wrote:
> On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> >>
> >>>
> >>> The Intel GPU uses a two pages NVS region called OpRegion.
> >>> In order to get full support for the driver in the guest
> >>> we need to map this region.
> >>>
> >>> This patch reserves 2 pages on the top of the RAM and
> >>> mark this region as NVS in the e820. Then we write the
> >>> address to the config space (offset 0xfc) so the device
> >>> model can map the OpRegion at this address in the guest.
> >>
> >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> >>
> >
> > Ok, that is handy.
> >
> >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> >>
> >
> > The OpRegion is a Intel GPU specific thing.
> >
> 
> Sorry didn't read carefully the first time, yes I think it's correct
> to do that for
> all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> a NVS region on the host, but that won't work for stub domain.

access to physical memory through /dev/mem should work from the stubdom

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Jean Guyader]

On 24/11 11:18, Stefano Stabellini wrote:
> On Wed, 23 Nov 2011, Jean Guyader wrote:
> > On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> > >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> > >>
> > >>>
> > >>> The Intel GPU uses a two pages NVS region called OpRegion.
> > >>> In order to get full support for the driver in the guest
> > >>> we need to map this region.
> > >>>
> > >>> This patch reserves 2 pages on the top of the RAM and
> > >>> mark this region as NVS in the e820. Then we write the
> > >>> address to the config space (offset 0xfc) so the device
> > >>> model can map the OpRegion at this address in the guest.
> > >>
> > >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> > >>
> > >
> > > Ok, that is handy.
> > >
> > >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> > >>
> > >
> > > The OpRegion is a Intel GPU specific thing.
> > >
> > 
> > Sorry didn't read carefully the first time, yes I think it's correct
> > to do that for
> > all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> > something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> > a NVS region on the host, but that won't work for stub domain.
> 
> access to physical memory through /dev/mem should work from the stubdom

I would think that /dev/mem in a stubdom will expose the memory of the guest but
maybe I'm wrong.

Jean

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Stefano Stabellini]

On Thu, 24 Nov 2011, Jean Guyader wrote:
> On 24/11 11:18, Stefano Stabellini wrote:
> > On Wed, 23 Nov 2011, Jean Guyader wrote:
> > > On 23 November 2011 17:28, Jean Guyader <jean.guyader@gmail.com> wrote:
> > > > On 23 November 2011 17:20, Keir Fraser <keir.xen@gmail.com> wrote:
> > > >> On 23/11/2011 16:07, "Jean Guyader" <jean.guyader@eu.citrix.com> wrote:
> > > >>
> > > >>>
> > > >>> The Intel GPU uses a two pages NVS region called OpRegion.
> > > >>> In order to get full support for the driver in the guest
> > > >>> we need to map this region.
> > > >>>
> > > >>> This patch reserves 2 pages on the top of the RAM and
> > > >>> mark this region as NVS in the e820. Then we write the
> > > >>> address to the config space (offset 0xfc) so the device
> > > >>> model can map the OpRegion at this address in the guest.
> > > >>
> > > >> Please use mem_hole_alloc() rather than adjusting {low,high}_mem_pgend.
> > > >>
> > > >
> > > > Ok, that is handy.
> > > >
> > > >> Is it correct to do this for *all* gfx devices with Intel vendor id?
> > > >>
> > > >
> > > > The OpRegion is a Intel GPU specific thing.
> > > >
> > > 
> > > Sorry didn't read carefully the first time, yes I think it's correct
> > > to do that for
> > > all the Intel GPU. Maybe I can do a read on 0xfc first to check if I don't get
> > > something dodgy like 0xfffffff or 0. I could also double check in Qemu that it's
> > > a NVS region on the host, but that won't work for stub domain.
> > 
> > access to physical memory through /dev/mem should work from the stubdom
> 
> I would think that /dev/mem in a stubdom will expose the memory of the guest but
> maybe I'm wrong.
> 
 
Nope, it maps host memory. Of course you need to make sure you have
given enough privileges to the stubdom so that it can actually map the
memory area.

[PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Jean Guyader]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]


The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the RAM and
mark this region as NVS in the e820. Then we write the
address to the config space (offset 0xfc) so the device
model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/firmware/hvmloader/config.h   |    1 +
 tools/firmware/hvmloader/e820.c     |   34 ++++++++++++++++++++++++++++++----
 tools/firmware/hvmloader/pci.c      |   14 ++++++++++++++
 tools/firmware/hvmloader/pci_regs.h |    2 ++
 4 files changed, 47 insertions(+), 4 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch --]
[-- Type: text/x-patch; name="0001-hvmloader-Intel-GPU-passthrough-reverse-OpRegion.patch", Size: 3452 bytes --]

diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index d911352..9cac9c1 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -5,6 +5,7 @@
 
 enum virtual_vga { VGA_none, VGA_std, VGA_cirrus, VGA_pt };
 extern enum virtual_vga virtual_vga;
+extern unsigned long igd_opregion_pgbase;
 
 struct bios_config {
     const char *name;
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 3b50dd0..0fc0b1c 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -128,11 +128,37 @@ int build_e820_table(struct e820entry *e820,
      * Explicitly reserve space for special pages.
      * This space starts at RESERVED_MEMBASE an extends to cover various
      * fixed hardware mappings (e.g., LAPIC, IOAPIC, default SVGA framebuffer).
+     *
+     * If igd_opregion_pgbase we need to split the RESERVED region in two.
      */
-    e820[nr].addr = RESERVED_MEMBASE;
-    e820[nr].size = (uint32_t)-e820[nr].addr;
-    e820[nr].type = E820_RESERVED;
-    nr++;
+
+    if ( igd_opregion_pgbase )
+    {
+        uint32_t igd_opregion_base = igd_opregion_pgbase << PAGE_SHIFT;
+
+        e820[nr].addr = RESERVED_MEMBASE;
+        e820[nr].size = (uint32_t) igd_opregion_base - RESERVED_MEMBASE;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+
+        e820[nr].addr = igd_opregion_base;
+        e820[nr].size = 2 * PAGE_SIZE;
+        e820[nr].type = E820_NVS;
+        nr++;
+
+        e820[nr].addr = igd_opregion_base + 2 * PAGE_SIZE;
+        e820[nr].size = (uint32_t)-e820[nr].addr;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+    }
+    else
+    {
+        e820[nr].addr = RESERVED_MEMBASE;
+        e820[nr].size = (uint32_t)-e820[nr].addr;
+        e820[nr].type = E820_RESERVED;
+        nr++;
+    }
+
 
     if ( hvm_info->high_mem_pgend )
     {
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 00490f1..2534530 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -32,6 +32,7 @@ unsigned long pci_mem_start = PCI_MEM_START;
 unsigned long pci_mem_end = PCI_MEM_END;
 
 enum virtual_vga virtual_vga = VGA_none;
+unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
@@ -95,6 +96,19 @@ void pci_setup(void)
             {
                 vga_devfn = devfn;
                 virtual_vga = VGA_pt;
+                if ( vendor_id == 0x8086 )
+                {
+                    igd_opregion_pgbase = mem_hole_alloc(2);
+
+                    /*
+                    ** Write the the OpRegion offset to give the opregion
+                    ** address to the device model.
+                    ** The device model will trap and map the OpRegion at
+                    ** the give address.
+                    */
+                    pci_writel(vga_devfn, PCI_INTEL_OPREGION,
+                            igd_opregion_pgbase << PAGE_SHIFT);
+                }
             }
             break;
         case 0x0680:
diff --git a/tools/firmware/hvmloader/pci_regs.h b/tools/firmware/hvmloader/pci_regs.h
index f37affe..0803f77 100644
--- a/tools/firmware/hvmloader/pci_regs.h
+++ b/tools/firmware/hvmloader/pci_regs.h
@@ -105,6 +105,8 @@
 #define PCI_MIN_GNT  0x3e /* 8 bits */
 #define PCI_MAX_LAT  0x3f /* 8 bits */
 
+#define PCI_INTEL_OPREGION 0xfc /* 4 bits */
+
 #endif /* __HVMLOADER_PCI_REGS_H__ */
 
 /*

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] hvmloader: Intel GPU passthrough, reverse OpRegion

[Jean Guyader]

The description was slightly wrong, here is a new one:

The Intel GPU uses a two pages NVS region called OpRegion.
In order to get full support for the driver in the guest
we need to map this region.

This patch reserves 2 pages on the top of the memory in the
reserved area and mark this region as NVS in the e820. Then
we write the address to the config space (offset 0xfc) so the
device model can map the OpRegion at this address in the guest.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

On 24 November 2011 14:53, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
>
> The Intel GPU uses a two pages NVS region called OpRegion.
> In order to get full support for the driver in the guest
> we need to map this region.
>
> This patch reserves 2 pages on the top of the RAM and
> mark this region as NVS in the e820. Then we write the
> address to the config space (offset 0xfc) so the device
> model can map the OpRegion at this address in the guest.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  tools/firmware/hvmloader/config.h   |    1 +
>  tools/firmware/hvmloader/e820.c     |   34 ++++++++++++++++++++++++++++++----
>  tools/firmware/hvmloader/pci.c      |   14 ++++++++++++++
>  tools/firmware/hvmloader/pci_regs.h |    2 ++
>  4 files changed, 47 insertions(+), 4 deletions(-)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>