[PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Jean Guyader]

The OpRegion shouldn't be mapped 1:1 because the address in the host
can't be used in the guest directly.

This patch traps read and write access to the opregion of the Intel
GPU config space (offset 0xfc).

To work correctly this patch needs a change in hvmloader.

HVMloader will allocate 2 pages for the OpRegion and write this address
on the config space of the Intel GPU. Qemu will trap and map the host
OpRegion to the guest. Any write to this offset after that won't have
any effect. Any read of this config space offset will return the address
in the guest.

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

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Jean Guyader]

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

On 12/01 12:41, Jean Guyader wrote:
> The OpRegion shouldn't be mapped 1:1 because the address in the host
> can't be used in the guest directly.
> 
> This patch traps read and write access to the opregion of the Intel
> GPU config space (offset 0xfc).
> 
> To work correctly this patch needs a change in hvmloader.
> 
> HVMloader will allocate 2 pages for the OpRegion and write this address
> on the config space of the Intel GPU. Qemu will trap and map the host
> OpRegion to the guest. Any write to this offset after that won't have
> any effect. Any read of this config space offset will return the address
> in the guest.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

Oups, patch is missing.

Jean

[-- Attachment #2: qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch --]
[-- Type: text/plain, Size: 8618 bytes --]

commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Wed Nov 23 07:53:30 2011 +0000

    qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
    
    The OpRegion shouldn't be mapped 1:1 because the address in the host
    can't be used in the guest directly.
    
    This patch traps read and write access to the opregion of the Intel
    GPU config space (offset 0xfc).
    
    To work correctly this patch needs a change in hvmloader.
    
    HVMloader will allocate 2 pages for the OpRegion and write this address
    on the config space of the Intel GPU. Qemu will trap and map the host
    OpRegion to the guest. Any write to this offset after that won't have
    any effect. Any read of this config space offset will return the address
    in the guest.

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..7ee3c61 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
 static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
     struct pt_reg_tbl *cfg_entry,
     uint32_t real_offset, uint32_t dev_value, uint32_t *value);
+static int pt_intel_opregion_read(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t valid_mask);
+static int pt_intel_opregion_write(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
+static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
+        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
 
 /* pt_reg_info_tbl declaration
  * - only for emulated register (either a part or whole bit).
@@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
         .u.dw.write = pt_exp_rom_bar_reg_write,
         .u.dw.restore = pt_exp_rom_bar_reg_restore,
     },
+    /* Intel IGFX OpRegion reg */
+    {
+        .offset     = PCI_INTEL_OPREGION,
+        .size       = 4,
+        .init_val   = 0,
+        .no_wb      = 1,
+        .u.dw.read   = pt_intel_opregion_read,
+        .u.dw.write  = pt_intel_opregion_write,
+        .u.dw.restore  = NULL,
+    },
     {
         .size = 0,
     },
@@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
         .grp_id     = 0xFF,
         .grp_type   = GRP_TYPE_EMU,
         .grp_size   = 0x40,
-        .size_init  = pt_reg_grp_size_init,
+        .size_init  = pt_reg_grp_header0_size_init,
         .emu_reg_tbl= pt_emu_reg_header0_tbl,
     },
     /* PCI PowerManagement Capability reg group */
@@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
     return reg->init_val;
 }
 
+static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
+        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
+{
+    /*
+    ** By default we will trap up to 0x40 in the cfg space.
+    ** If an intel device is pass through we need to trap 0xfc,
+    ** therefore the size should be 0xff.
+    */
+    if (igd_passthru)
+        return 0xFF;
+    return grp_reg->grp_size;
+}
+
 /* get register group size */
 static uint8_t pt_reg_grp_size_init(struct pt_dev *ptdev,
         struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
@@ -4154,6 +4185,22 @@ static int pt_pmcsr_reg_restore(struct pt_dev *ptdev,
     return 0;
 }
 
+static int pt_intel_opregion_read(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t valid_mask)
+{
+    *value = igd_read_opregion(ptdev);
+    return 0;
+}
+
+static int pt_intel_opregion_write(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t dev_value, uint32_t valid_mask)
+{
+    igd_write_opregion(ptdev, *value);
+    return 0;
+}
+
 static struct pt_dev * register_real_device(PCIBus *e_bus,
         const char *e_dev_name, int e_devfn, uint8_t r_bus, uint8_t r_dev,
         uint8_t r_func, uint32_t machine_irq, struct pci_access *pci_access,
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..c61a7fb 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -422,6 +422,8 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+uint32_t igd_read_opregion(struct pt_dev *pci_dev);
+void igd_write_opregion(struct pt_dev *real_dev, uint32_t val);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..a60673f 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -13,6 +13,8 @@
 extern int gfx_passthru;
 extern int igd_passthru;
 
+static uint32_t igd_guest_opregion = 0;
+
 static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
 {
     PT_LOG("pch_map_irq called\n");
@@ -37,6 +39,54 @@ void intel_pch_init(PCIBus *bus)
                         pch_map_irq, "intel_bridge_1f");
 }
 
+uint32_t igd_read_opregion(struct pt_dev *pci_dev)
+{
+    uint32_t val = -1;
+
+    if ( igd_guest_opregion == 0 )
+        return -1;
+
+    val = igd_guest_opregion;
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV((PCIDevice*)pci_dev, "addr=%x len=%x val=%x\n",
+            PCI_INTEL_OPREGION, 4, val);
+#endif
+    return val;
+}
+
+void igd_write_opregion(struct pt_dev *real_dev, uint32_t val)
+{
+    uint32_t host_opregion = 0;
+    int ret;
+
+    if ( igd_guest_opregion )
+    {
+        PT_LOG("opregion register already been set, ignoring %x\n", val);
+        return;
+    }
+
+    host_opregion = pt_pci_host_read(real_dev->pci_dev, PCI_INTEL_OPREGION, 4);
+    igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff);
+    PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion);
+
+    ret = xc_domain_memory_mapping(xc_handle, domid,
+            igd_guest_opregion >> XC_PAGE_SHIFT,
+            host_opregion >> XC_PAGE_SHIFT,
+            2,
+            DPCI_ADD_MAPPING);
+
+    if ( ret != 0 )
+    {
+        PT_LOG("Error: Can't map opregion\n");
+        igd_guest_opregion = 0;
+    }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV((PCIDevice*)real_dev, "addr=%x len=%lx val=%x\n",
+            PCI_INTEL_OPREGION, len, val);
+#endif
+
+}
+
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -99,7 +149,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 int register_vga_regions(struct pt_dev *real_device)
 {
     u16 vendor_id;
-    int igd_opregion;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -117,19 +166,6 @@ int register_vga_regions(struct pt_dev *real_device)
             0x20,
             DPCI_ADD_MAPPING);
 
-    /* 1:1 map ASL Storage register value */
-    vendor_id = pt_pci_host_read(real_device->pci_dev, 0, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL ) && igd_opregion )
-    {
-        ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
-                2,
-                DPCI_ADD_MAPPING);
-        PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
-    }
-
     if ( ret != 0 )
         PT_LOG("VGA region mapping failed\n");
 
@@ -141,7 +177,7 @@ int register_vga_regions(struct pt_dev *real_device)
  */
 int unregister_vga_regions(struct pt_dev *real_device)
 {
-    u32 vendor_id, igd_opregion;
+    u32 vendor_id;
     int ret = 0;
 
     if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
@@ -160,12 +196,11 @@ int unregister_vga_regions(struct pt_dev *real_device)
             DPCI_REMOVE_MAPPING);
 
     vendor_id = pt_pci_host_read(real_device->pci_dev, PCI_VENDOR_ID, 2);
-    igd_opregion = pt_pci_host_read(real_device->pci_dev, PCI_INTEL_OPREGION, 4);
-    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_opregion )
+    if ( (vendor_id == PCI_VENDOR_ID_INTEL) && igd_guest_opregion )
     {
         ret |= xc_domain_memory_mapping(xc_handle, domid,
-                igd_opregion >> XC_PAGE_SHIFT,
-                igd_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
+                igd_guest_opregion >> XC_PAGE_SHIFT,
                 2,
                 DPCI_REMOVE_MAPPING);
     }

[-- 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] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Stefano Stabellini]

On Thu, 12 Jan 2012, Jean Guyader wrote:
> On 12/01 12:41, Jean Guyader wrote:
> > The OpRegion shouldn't be mapped 1:1 because the address in the host
> > can't be used in the guest directly.
> > 
> > This patch traps read and write access to the opregion of the Intel
> > GPU config space (offset 0xfc).
> > 
> > To work correctly this patch needs a change in hvmloader.
> > 
> > HVMloader will allocate 2 pages for the OpRegion and write this address
> > on the config space of the Intel GPU. Qemu will trap and map the host
> > OpRegion to the guest. Any write to this offset after that won't have
> > any effect. Any read of this config space offset will return the address
> > in the guest.
> > 
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> Date:   Wed Nov 23 07:53:30 2011 +0000
> 
>     qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
>     
>     The OpRegion shouldn't be mapped 1:1 because the address in the host
>     can't be used in the guest directly.
>     
>     This patch traps read and write access to the opregion of the Intel
>     GPU config space (offset 0xfc).
>     
>     To work correctly this patch needs a change in hvmloader.
>     
>     HVMloader will allocate 2 pages for the OpRegion and write this address
>     on the config space of the Intel GPU. Qemu will trap and map the host
>     OpRegion to the guest. Any write to this offset after that won't have
>     any effect. Any read of this config space offset will return the address
>     in the guest.
> 
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index dbe8804..7ee3c61 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
>  static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
>      struct pt_reg_tbl *cfg_entry,
>      uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t valid_mask);
> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> +        struct pt_reg_tbl *cfg_entry,
> +        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
>  
>  /* pt_reg_info_tbl declaration
>   * - only for emulated register (either a part or whole bit).
> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
>          .u.dw.write = pt_exp_rom_bar_reg_write,
>          .u.dw.restore = pt_exp_rom_bar_reg_restore,
>      },
> +    /* Intel IGFX OpRegion reg */
> +    {
> +        .offset     = PCI_INTEL_OPREGION,
> +        .size       = 4,
> +        .init_val   = 0,
> +        .no_wb      = 1,
> +        .u.dw.read   = pt_intel_opregion_read,
> +        .u.dw.write  = pt_intel_opregion_write,
> +        .u.dw.restore  = NULL,
> +    },
>      {
>          .size = 0,
>      },
> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
>          .grp_id     = 0xFF,
>          .grp_type   = GRP_TYPE_EMU,
>          .grp_size   = 0x40,
> -        .size_init  = pt_reg_grp_size_init,
> +        .size_init  = pt_reg_grp_header0_size_init,
>          .emu_reg_tbl= pt_emu_reg_header0_tbl,
>      },
>      /* PCI PowerManagement Capability reg group */
> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
>      return reg->init_val;
>  }
>  
> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> +{
> +    /*
> +    ** By default we will trap up to 0x40 in the cfg space.
> +    ** If an intel device is pass through we need to trap 0xfc,
> +    ** therefore the size should be 0xff.
> +    */
> +    if (igd_passthru)
> +        return 0xFF;
> +    return grp_reg->grp_size;
> +}

Apart from the trivial code style error in the comment above, is this
going to have the unintended side effect of initializing as 0 all the
emulated registers between 0x40 and 0xff, that previously were probably
passed through?

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Jean Guyader]

On 12 January 2012 14:34, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 12 Jan 2012, Jean Guyader wrote:
>> On 12/01 12:41, Jean Guyader wrote:
>> > The OpRegion shouldn't be mapped 1:1 because the address in the host
>> > can't be used in the guest directly.
>> >
>> > This patch traps read and write access to the opregion of the Intel
>> > GPU config space (offset 0xfc).
>> >
>> > To work correctly this patch needs a change in hvmloader.
>> >
>> > HVMloader will allocate 2 pages for the OpRegion and write this address
>> > on the config space of the Intel GPU. Qemu will trap and map the host
>> > OpRegion to the guest. Any write to this offset after that won't have
>> > any effect. Any read of this config space offset will return the address
>> > in the guest.
>> >
>> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
>> Author: Jean Guyader <jean.guyader@eu.citrix.com>
>> Date:   Wed Nov 23 07:53:30 2011 +0000
>>
>>     qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
>>
>>     The OpRegion shouldn't be mapped 1:1 because the address in the host
>>     can't be used in the guest directly.
>>
>>     This patch traps read and write access to the opregion of the Intel
>>     GPU config space (offset 0xfc).
>>
>>     To work correctly this patch needs a change in hvmloader.
>>
>>     HVMloader will allocate 2 pages for the OpRegion and write this address
>>     on the config space of the Intel GPU. Qemu will trap and map the host
>>     OpRegion to the guest. Any write to this offset after that won't have
>>     any effect. Any read of this config space offset will return the address
>>     in the guest.
>>
>> diff --git a/hw/pass-through.c b/hw/pass-through.c
>> index dbe8804..7ee3c61 100644
>> --- a/hw/pass-through.c
>> +++ b/hw/pass-through.c
>> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
>>  static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
>>      struct pt_reg_tbl *cfg_entry,
>>      uint32_t real_offset, uint32_t dev_value, uint32_t *value);
>> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
>> +        struct pt_reg_tbl *cfg_entry,
>> +        uint32_t *value, uint32_t valid_mask);
>> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
>> +        struct pt_reg_tbl *cfg_entry,
>> +        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
>> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
>>
>>  /* pt_reg_info_tbl declaration
>>   * - only for emulated register (either a part or whole bit).
>> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
>>          .u.dw.write = pt_exp_rom_bar_reg_write,
>>          .u.dw.restore = pt_exp_rom_bar_reg_restore,
>>      },
>> +    /* Intel IGFX OpRegion reg */
>> +    {
>> +        .offset     = PCI_INTEL_OPREGION,
>> +        .size       = 4,
>> +        .init_val   = 0,
>> +        .no_wb      = 1,
>> +        .u.dw.read   = pt_intel_opregion_read,
>> +        .u.dw.write  = pt_intel_opregion_write,
>> +        .u.dw.restore  = NULL,
>> +    },
>>      {
>>          .size = 0,
>>      },
>> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
>>          .grp_id     = 0xFF,
>>          .grp_type   = GRP_TYPE_EMU,
>>          .grp_size   = 0x40,
>> -        .size_init  = pt_reg_grp_size_init,
>> +        .size_init  = pt_reg_grp_header0_size_init,
>>          .emu_reg_tbl= pt_emu_reg_header0_tbl,
>>      },
>>      /* PCI PowerManagement Capability reg group */
>> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
>>      return reg->init_val;
>>  }
>>
>> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
>> +{
>> +    /*
>> +    ** By default we will trap up to 0x40 in the cfg space.
>> +    ** If an intel device is pass through we need to trap 0xfc,
>> +    ** therefore the size should be 0xff.
>> +    */
>> +    if (igd_passthru)
>> +        return 0xFF;
>> +    return grp_reg->grp_size;
>> +}
>
> Apart from the trivial code style error in the comment above, is this
> going to have the unintended side effect of initializing as 0 all the
> emulated registers between 0x40 and 0xff, that previously were probably
> passed through?
>

Based on how pt_find_reg_grp is implemented that doesn't make any difference.

Jean

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Stefano Stabellini]

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

On Mon, 16 Jan 2012, Jean Guyader wrote:
> On 12 January 2012 14:34, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 12 Jan 2012, Jean Guyader wrote:
> >> On 12/01 12:41, Jean Guyader wrote:
> >> > The OpRegion shouldn't be mapped 1:1 because the address in the host
> >> > can't be used in the guest directly.
> >> >
> >> > This patch traps read and write access to the opregion of the Intel
> >> > GPU config space (offset 0xfc).
> >> >
> >> > To work correctly this patch needs a change in hvmloader.
> >> >
> >> > HVMloader will allocate 2 pages for the OpRegion and write this address
> >> > on the config space of the Intel GPU. Qemu will trap and map the host
> >> > OpRegion to the guest. Any write to this offset after that won't have
> >> > any effect. Any read of this config space offset will return the address
> >> > in the guest.
> >> >
> >> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> >> Date:   Wed Nov 23 07:53:30 2011 +0000
> >>
> >>     qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
> >>
> >>     The OpRegion shouldn't be mapped 1:1 because the address in the host
> >>     can't be used in the guest directly.
> >>
> >>     This patch traps read and write access to the opregion of the Intel
> >>     GPU config space (offset 0xfc).
> >>
> >>     To work correctly this patch needs a change in hvmloader.
> >>
> >>     HVMloader will allocate 2 pages for the OpRegion and write this address
> >>     on the config space of the Intel GPU. Qemu will trap and map the host
> >>     OpRegion to the guest. Any write to this offset after that won't have
> >>     any effect. Any read of this config space offset will return the address
> >>     in the guest.
> >>
> >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> >> index dbe8804..7ee3c61 100644
> >> --- a/hw/pass-through.c
> >> +++ b/hw/pass-through.c
> >> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
> >>  static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
> >>      struct pt_reg_tbl *cfg_entry,
> >>      uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> >> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> >> +        struct pt_reg_tbl *cfg_entry,
> >> +        uint32_t *value, uint32_t valid_mask);
> >> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> >> +        struct pt_reg_tbl *cfg_entry,
> >> +        uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> >> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
> >>
> >>  /* pt_reg_info_tbl declaration
> >>   * - only for emulated register (either a part or whole bit).
> >> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
> >>          .u.dw.write = pt_exp_rom_bar_reg_write,
> >>          .u.dw.restore = pt_exp_rom_bar_reg_restore,
> >>      },
> >> +    /* Intel IGFX OpRegion reg */
> >> +    {
> >> +        .offset     = PCI_INTEL_OPREGION,
> >> +        .size       = 4,
> >> +        .init_val   = 0,
> >> +        .no_wb      = 1,
> >> +        .u.dw.read   = pt_intel_opregion_read,
> >> +        .u.dw.write  = pt_intel_opregion_write,
> >> +        .u.dw.restore  = NULL,
> >> +    },
> >>      {
> >>          .size = 0,
> >>      },
> >> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
> >>          .grp_id     = 0xFF,
> >>          .grp_type   = GRP_TYPE_EMU,
> >>          .grp_size   = 0x40,
> >> -        .size_init  = pt_reg_grp_size_init,
> >> +        .size_init  = pt_reg_grp_header0_size_init,
> >>          .emu_reg_tbl= pt_emu_reg_header0_tbl,
> >>      },
> >>      /* PCI PowerManagement Capability reg group */
> >> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
> >>      return reg->init_val;
> >>  }
> >>
> >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> >> +        struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> >> +{
> >> +    /*
> >> +    ** By default we will trap up to 0x40 in the cfg space.
> >> +    ** If an intel device is pass through we need to trap 0xfc,
> >> +    ** therefore the size should be 0xff.
> >> +    */
> >> +    if (igd_passthru)
> >> +        return 0xFF;
> >> +    return grp_reg->grp_size;
> >> +}
> >
> > Apart from the trivial code style error in the comment above, is this
> > going to have the unintended side effect of initializing as 0 all the
> > emulated registers between 0x40 and 0xff, that previously were probably
> > passed through?
> >
> 
> Based on how pt_find_reg_grp is implemented that doesn't make any difference.
 
actually there is a small change in behaviour: before your patch
pt_find_reg_grp would return NULL for any cfg register between 0x40 and
0xff. Now if igd_passthru is set pt_find_reg_grp would return the
reg_grp_entry corresponding to "Header Type0 reg group" and then
pt_find_reg would return NULL.
This case seems to be handled correctly and bring to the same results
in both pt_pci_write_config and pt_pci_read_config.

In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
group" only it if really is part of this group otherwise it should be in
its own separate group.

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

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

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Jean Guyader]

On 17/01 02:51, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Jean Guyader wrote:
> > On 12 January 2012 14:34, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > >> On 12/01 12:41, Jean Guyader wrote:
> > >> > The OpRegion shouldn't be mapped 1:1 because the address in the host
> > >> > can't be used in the guest directly.
> > >> >
> > >> > This patch traps read and write access to the opregion of the Intel
> > >> > GPU config space (offset 0xfc).
> > >> >
> > >> > To work correctly this patch needs a change in hvmloader.
> > >> >
> > >> > HVMloader will allocate 2 pages for the OpRegion and write this address
> > >> > on the config space of the Intel GPU. Qemu will trap and map the host
> > >> > OpRegion to the guest. Any write to this offset after that won't have
> > >> > any effect. Any read of this config space offset will return the address
> > >> > in the guest.
> > >> >
> > >> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > >>
> > >> ?? ?? qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
> > >>
> > >> ?? ?? The OpRegion shouldn't be mapped 1:1 because the address in the host
> > >> ?? ?? can't be used in the guest directly.
> > >>
> > >> ?? ?? This patch traps read and write access to the opregion of the Intel
> > >> ?? ?? GPU config space (offset 0xfc).
> > >>
> > >> ?? ?? To work correctly this patch needs a change in hvmloader.
> > >>
> > >> ?? ?? HVMloader will allocate 2 pages for the OpRegion and write this address
> > >> ?? ?? on the config space of the Intel GPU. Qemu will trap and map the host
> > >> ?? ?? OpRegion to the guest. Any write to this offset after that won't have
> > >> ?? ?? any effect. Any read of this config space offset will return the address
> > >> ?? ?? in the guest.
> > >>
> > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > >> index dbe8804..7ee3c61 100644
> > >> --- a/hw/pass-through.c
> > >> +++ b/hw/pass-through.c
> > >> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
> > >> ??static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
> > >> ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > >> ?? ?? ??uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> > >> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > >> + ?? ?? ?? ??uint32_t *value, uint32_t valid_mask);
> > >> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > >> + ?? ?? ?? ??uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
> > >>
> > >> ??/* pt_reg_info_tbl declaration
> > >> ?? * - only for emulated register (either a part or whole bit).
> > >> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
> > >> ?? ?? ?? ?? ??.u.dw.write = pt_exp_rom_bar_reg_write,
> > >> ?? ?? ?? ?? ??.u.dw.restore = pt_exp_rom_bar_reg_restore,
> > >> ?? ?? ??},
> > >> + ?? ??/* Intel IGFX OpRegion reg */
> > >> + ?? ??{
> > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > >> + ?? ?? ?? ??.init_val ?? = 0,
> > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > >> + ?? ??},
> > >> ?? ?? ??{
> > >> ?? ?? ?? ?? ??.size = 0,
> > >> ?? ?? ??},
> > >> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
> > >> ?? ?? ?? ?? ??.grp_id ?? ?? = 0xFF,
> > >> ?? ?? ?? ?? ??.grp_type ?? = GRP_TYPE_EMU,
> > >> ?? ?? ?? ?? ??.grp_size ?? = 0x40,
> > >> - ?? ?? ?? ??.size_init ??= pt_reg_grp_size_init,
> > >> + ?? ?? ?? ??.size_init ??= pt_reg_grp_header0_size_init,
> > >> ?? ?? ?? ?? ??.emu_reg_tbl= pt_emu_reg_header0_tbl,
> > >> ?? ?? ??},
> > >> ?? ?? ??/* PCI PowerManagement Capability reg group */
> > >> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
> > >> ?? ?? ??return reg->init_val;
> > >> ??}
> > >>
> > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> > >> +{
> > >> + ?? ??/*
> > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > >> + ?? ??** therefore the size should be 0xff.
> > >> + ?? ??*/
> > >> + ?? ??if (igd_passthru)
> > >> + ?? ?? ?? ??return 0xFF;
> > >> + ?? ??return grp_reg->grp_size;
> > >> +}
> > >
> > > Apart from the trivial code style error in the comment above, is this
> > > going to have the unintended side effect of initializing as 0 all the
> > > emulated registers between 0x40 and 0xff, that previously were probably
> > > passed through?
> > >
> > 
> > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
>  
> actually there is a small change in behaviour: before your patch
> pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> reg_grp_entry corresponding to "Header Type0 reg group" and then
> pt_find_reg would return NULL.
> This case seems to be handled correctly and bring to the same results
> in both pt_pci_write_config and pt_pci_read_config.
> 
> In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> group" only it if really is part of this group otherwise it should be in
> its own separate group.

The pci pass through groups have been designed to pass through pci capabilities
from the device. You can't really create a group for something which isn't a pci
capability.

I have noted the change of behavior but that doesn't have any impact on what we
will return to the guest so I think it fine.

Jean

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Stefano Stabellini]

On Tue, 17 Jan 2012, Jean Guyader wrote:
> On 17/01 02:51, Stefano Stabellini wrote:
> > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > On 12 January 2012 14:34, Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > >> On 12/01 12:41, Jean Guyader wrote:
> > > >> > The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > >> > can't be used in the guest directly.
> > > >> >
> > > >> > This patch traps read and write access to the opregion of the Intel
> > > >> > GPU config space (offset 0xfc).
> > > >> >
> > > >> > To work correctly this patch needs a change in hvmloader.
> > > >> >
> > > >> > HVMloader will allocate 2 pages for the OpRegion and write this address
> > > >> > on the config space of the Intel GPU. Qemu will trap and map the host
> > > >> > OpRegion to the guest. Any write to this offset after that won't have
> > > >> > any effect. Any read of this config space offset will return the address
> > > >> > in the guest.
> > > >> >
> > > >> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > >>
> > > >> ?? ?? qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
> > > >>
> > > >> ?? ?? The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > >> ?? ?? can't be used in the guest directly.
> > > >>
> > > >> ?? ?? This patch traps read and write access to the opregion of the Intel
> > > >> ?? ?? GPU config space (offset 0xfc).
> > > >>
> > > >> ?? ?? To work correctly this patch needs a change in hvmloader.
> > > >>
> > > >> ?? ?? HVMloader will allocate 2 pages for the OpRegion and write this address
> > > >> ?? ?? on the config space of the Intel GPU. Qemu will trap and map the host
> > > >> ?? ?? OpRegion to the guest. Any write to this offset after that won't have
> > > >> ?? ?? any effect. Any read of this config space offset will return the address
> > > >> ?? ?? in the guest.
> > > >>
> > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > >> index dbe8804..7ee3c61 100644
> > > >> --- a/hw/pass-through.c
> > > >> +++ b/hw/pass-through.c
> > > >> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
> > > >> ??static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
> > > >> ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > >> ?? ?? ??uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> > > >> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > >> + ?? ?? ?? ??uint32_t *value, uint32_t valid_mask);
> > > >> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > >> + ?? ?? ?? ??uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
> > > >>
> > > >> ??/* pt_reg_info_tbl declaration
> > > >> ?? * - only for emulated register (either a part or whole bit).
> > > >> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
> > > >> ?? ?? ?? ?? ??.u.dw.write = pt_exp_rom_bar_reg_write,
> > > >> ?? ?? ?? ?? ??.u.dw.restore = pt_exp_rom_bar_reg_restore,
> > > >> ?? ?? ??},
> > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > >> + ?? ??{
> > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > >> + ?? ??},
> > > >> ?? ?? ??{
> > > >> ?? ?? ?? ?? ??.size = 0,
> > > >> ?? ?? ??},
> > > >> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
> > > >> ?? ?? ?? ?? ??.grp_id ?? ?? = 0xFF,
> > > >> ?? ?? ?? ?? ??.grp_type ?? = GRP_TYPE_EMU,
> > > >> ?? ?? ?? ?? ??.grp_size ?? = 0x40,
> > > >> - ?? ?? ?? ??.size_init ??= pt_reg_grp_size_init,
> > > >> + ?? ?? ?? ??.size_init ??= pt_reg_grp_header0_size_init,
> > > >> ?? ?? ?? ?? ??.emu_reg_tbl= pt_emu_reg_header0_tbl,
> > > >> ?? ?? ??},
> > > >> ?? ?? ??/* PCI PowerManagement Capability reg group */
> > > >> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
> > > >> ?? ?? ??return reg->init_val;
> > > >> ??}
> > > >>
> > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> > > >> +{
> > > >> + ?? ??/*
> > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > >> + ?? ??** therefore the size should be 0xff.
> > > >> + ?? ??*/
> > > >> + ?? ??if (igd_passthru)
> > > >> + ?? ?? ?? ??return 0xFF;
> > > >> + ?? ??return grp_reg->grp_size;
> > > >> +}
> > > >
> > > > Apart from the trivial code style error in the comment above, is this
> > > > going to have the unintended side effect of initializing as 0 all the
> > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > passed through?
> > > >
> > > 
> > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> >  
> > actually there is a small change in behaviour: before your patch
> > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > pt_find_reg would return NULL.
> > This case seems to be handled correctly and bring to the same results
> > in both pt_pci_write_config and pt_pci_read_config.
> > 
> > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > group" only it if really is part of this group otherwise it should be in
> > its own separate group.
> 
> The pci pass through groups have been designed to pass through pci capabilities
> from the device. You can't really create a group for something which isn't a pci
> capability.
> 
> I have noted the change of behavior but that doesn't have any impact on what we
> will return to the guest so I think it fine.
 
in that case, ack

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Jean Guyader]

On 17/01 04:34, Stefano Stabellini wrote:
> On Tue, 17 Jan 2012, Jean Guyader wrote:
> > On 17/01 02:51, Stefano Stabellini wrote:
> > > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > > On 12 January 2012 14:34, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > > >> On 12/01 12:41, Jean Guyader wrote:
> > > > >> > The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > > >> > can't be used in the guest directly.
> > > > >> >
> > > > >> > This patch traps read and write access to the opregion of the Intel
> > > > >> > GPU config space (offset 0xfc).
> > > > >> >
> > > > >> > To work correctly this patch needs a change in hvmloader.
> > > > >> >
> > > > >> > HVMloader will allocate 2 pages for the OpRegion and write this address
> > > > >> > on the config space of the Intel GPU. Qemu will trap and map the host
> > > > >> > OpRegion to the guest. Any write to this offset after that won't have
> > > > >> > any effect. Any read of this config space offset will return the address
> > > > >> > in the guest.
> > > > >> >
> > > > >> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > > >>
> > > > >> ?? ?? qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
> > > > >>
> > > > >> ?? ?? The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > > >> ?? ?? can't be used in the guest directly.
> > > > >>
> > > > >> ?? ?? This patch traps read and write access to the opregion of the Intel
> > > > >> ?? ?? GPU config space (offset 0xfc).
> > > > >>
> > > > >> ?? ?? To work correctly this patch needs a change in hvmloader.
> > > > >>
> > > > >> ?? ?? HVMloader will allocate 2 pages for the OpRegion and write this address
> > > > >> ?? ?? on the config space of the Intel GPU. Qemu will trap and map the host
> > > > >> ?? ?? OpRegion to the guest. Any write to this offset after that won't have
> > > > >> ?? ?? any effect. Any read of this config space offset will return the address
> > > > >> ?? ?? in the guest.
> > > > >>
> > > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > > >> index dbe8804..7ee3c61 100644
> > > > >> --- a/hw/pass-through.c
> > > > >> +++ b/hw/pass-through.c
> > > > >> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
> > > > >> ??static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
> > > > >> ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > >> ?? ?? ??uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> > > > >> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t valid_mask);
> > > > >> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
> > > > >>
> > > > >> ??/* pt_reg_info_tbl declaration
> > > > >> ?? * - only for emulated register (either a part or whole bit).
> > > > >> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
> > > > >> ?? ?? ?? ?? ??.u.dw.write = pt_exp_rom_bar_reg_write,
> > > > >> ?? ?? ?? ?? ??.u.dw.restore = pt_exp_rom_bar_reg_restore,
> > > > >> ?? ?? ??},
> > > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > > >> + ?? ??{
> > > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > > >> + ?? ??},
> > > > >> ?? ?? ??{
> > > > >> ?? ?? ?? ?? ??.size = 0,
> > > > >> ?? ?? ??},
> > > > >> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
> > > > >> ?? ?? ?? ?? ??.grp_id ?? ?? = 0xFF,
> > > > >> ?? ?? ?? ?? ??.grp_type ?? = GRP_TYPE_EMU,
> > > > >> ?? ?? ?? ?? ??.grp_size ?? = 0x40,
> > > > >> - ?? ?? ?? ??.size_init ??= pt_reg_grp_size_init,
> > > > >> + ?? ?? ?? ??.size_init ??= pt_reg_grp_header0_size_init,
> > > > >> ?? ?? ?? ?? ??.emu_reg_tbl= pt_emu_reg_header0_tbl,
> > > > >> ?? ?? ??},
> > > > >> ?? ?? ??/* PCI PowerManagement Capability reg group */
> > > > >> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
> > > > >> ?? ?? ??return reg->init_val;
> > > > >> ??}
> > > > >>
> > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> > > > >> +{
> > > > >> + ?? ??/*
> > > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > > >> + ?? ??** therefore the size should be 0xff.
> > > > >> + ?? ??*/
> > > > >> + ?? ??if (igd_passthru)
> > > > >> + ?? ?? ?? ??return 0xFF;
> > > > >> + ?? ??return grp_reg->grp_size;
> > > > >> +}
> > > > >
> > > > > Apart from the trivial code style error in the comment above, is this
> > > > > going to have the unintended side effect of initializing as 0 all the
> > > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > > passed through?
> > > > >
> > > > 
> > > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> > >  
> > > actually there is a small change in behaviour: before your patch
> > > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > > pt_find_reg would return NULL.
> > > This case seems to be handled correctly and bring to the same results
> > > in both pt_pci_write_config and pt_pci_read_config.
> > > 
> > > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > > group" only it if really is part of this group otherwise it should be in
> > > its own separate group.
> > 
> > The pci pass through groups have been designed to pass through pci capabilities
> > from the device. You can't really create a group for something which isn't a pci
> > capability.
> > 
> > I have noted the change of behavior but that doesn't have any impact on what we
> > will return to the guest so I think it fine.
>  
> in that case, ack

Ian,

Could you apply this patch please?

Jean

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Jean Guyader]

On 31 January 2012 14:51, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
>
> On 17/01 04:34, Stefano Stabellini wrote:
> > On Tue, 17 Jan 2012, Jean Guyader wrote:
> > > On 17/01 02:51, Stefano Stabellini wrote:
> > > > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > > > On 12 January 2012 14:34, Stefano Stabellini
> > > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > > > >> On 12/01 12:41, Jean Guyader wrote:
> > > > > >> > The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > > > >> > can't be used in the guest directly.
> > > > > >> >
> > > > > >> > This patch traps read and write access to the opregion of the Intel
> > > > > >> > GPU config space (offset 0xfc).
> > > > > >> >
> > > > > >> > To work correctly this patch needs a change in hvmloader.
> > > > > >> >
> > > > > >> > HVMloader will allocate 2 pages for the OpRegion and write this address
> > > > > >> > on the config space of the Intel GPU. Qemu will trap and map the host
> > > > > >> > OpRegion to the guest. Any write to this offset after that won't have
> > > > > >> > any effect. Any read of this config space offset will return the address
> > > > > >> > in the guest.
> > > > > >> >
> > > > > >> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > > > >>
> > > > > >> ?? ?? qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
> > > > > >>
> > > > > >> ?? ?? The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > > > >> ?? ?? can't be used in the guest directly.
> > > > > >>
> > > > > >> ?? ?? This patch traps read and write access to the opregion of the Intel
> > > > > >> ?? ?? GPU config space (offset 0xfc).
> > > > > >>
> > > > > >> ?? ?? To work correctly this patch needs a change in hvmloader.
> > > > > >>
> > > > > >> ?? ?? HVMloader will allocate 2 pages for the OpRegion and write this address
> > > > > >> ?? ?? on the config space of the Intel GPU. Qemu will trap and map the host
> > > > > >> ?? ?? OpRegion to the guest. Any write to this offset after that won't have
> > > > > >> ?? ?? any effect. Any read of this config space offset will return the address
> > > > > >> ?? ?? in the guest.
> > > > > >>
> > > > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > > > >> index dbe8804..7ee3c61 100644
> > > > > >> --- a/hw/pass-through.c
> > > > > >> +++ b/hw/pass-through.c
> > > > > >> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
> > > > > >> ??static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
> > > > > >> ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > > >> ?? ?? ??uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> > > > > >> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t valid_mask);
> > > > > >> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> > > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
> > > > > >>
> > > > > >> ??/* pt_reg_info_tbl declaration
> > > > > >> ?? * - only for emulated register (either a part or whole bit).
> > > > > >> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
> > > > > >> ?? ?? ?? ?? ??.u.dw.write = pt_exp_rom_bar_reg_write,
> > > > > >> ?? ?? ?? ?? ??.u.dw.restore = pt_exp_rom_bar_reg_restore,
> > > > > >> ?? ?? ??},
> > > > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > > > >> + ?? ??{
> > > > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > > > >> + ?? ??},
> > > > > >> ?? ?? ??{
> > > > > >> ?? ?? ?? ?? ??.size = 0,
> > > > > >> ?? ?? ??},
> > > > > >> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
> > > > > >> ?? ?? ?? ?? ??.grp_id ?? ?? = 0xFF,
> > > > > >> ?? ?? ?? ?? ??.grp_type ?? = GRP_TYPE_EMU,
> > > > > >> ?? ?? ?? ?? ??.grp_size ?? = 0x40,
> > > > > >> - ?? ?? ?? ??.size_init ??= pt_reg_grp_size_init,
> > > > > >> + ?? ?? ?? ??.size_init ??= pt_reg_grp_header0_size_init,
> > > > > >> ?? ?? ?? ?? ??.emu_reg_tbl= pt_emu_reg_header0_tbl,
> > > > > >> ?? ?? ??},
> > > > > >> ?? ?? ??/* PCI PowerManagement Capability reg group */
> > > > > >> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
> > > > > >> ?? ?? ??return reg->init_val;
> > > > > >> ??}
> > > > > >>
> > > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> > > > > >> +{
> > > > > >> + ?? ??/*
> > > > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > > > >> + ?? ??** therefore the size should be 0xff.
> > > > > >> + ?? ??*/
> > > > > >> + ?? ??if (igd_passthru)
> > > > > >> + ?? ?? ?? ??return 0xFF;
> > > > > >> + ?? ??return grp_reg->grp_size;
> > > > > >> +}
> > > > > >
> > > > > > Apart from the trivial code style error in the comment above, is this
> > > > > > going to have the unintended side effect of initializing as 0 all the
> > > > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > > > passed through?
> > > > > >
> > > > >
> > > > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> > > >
> > > > actually there is a small change in behaviour: before your patch
> > > > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > > > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > > > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > > > pt_find_reg would return NULL.
> > > > This case seems to be handled correctly and bring to the same results
> > > > in both pt_pci_write_config and pt_pci_read_config.
> > > >
> > > > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > > > group" only it if really is part of this group otherwise it should be in
> > > > its own separate group.
> > >
> > > The pci pass through groups have been designed to pass through pci capabilities
> > > from the device. You can't really create a group for something which isn't a pci
> > > capability.
> > >
> > > I have noted the change of behavior but that doesn't have any impact on what we
> > > will return to the guest so I think it fine.
> >
> > in that case, ack
>
> Ian,
>
> Could you apply this patch please?
>

Hi Ian,

I was going through my email and it seems that this patch didn't make
it into qemu-xen-unstable.

Thanks,
Jean

Re: [PATCH] qemu-xen: Intel GPU passthrough, fix OpRegion mapping. (v3)

[Jean Guyader]

On 31 January 2012 14:51, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
> On 17/01 04:34, Stefano Stabellini wrote:
>> On Tue, 17 Jan 2012, Jean Guyader wrote:
>> > On 17/01 02:51, Stefano Stabellini wrote:
>> > > On Mon, 16 Jan 2012, Jean Guyader wrote:
>> > > > On 12 January 2012 14:34, Stefano Stabellini
>> > > > <stefano.stabellini@eu.citrix.com> wrote:
>> > > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
>> > > > >> On 12/01 12:41, Jean Guyader wrote:
>> > > > >> > The OpRegion shouldn't be mapped 1:1 because the address in the host
>> > > > >> > can't be used in the guest directly.
>> > > > >> >
>> > > > >> > This patch traps read and write access to the opregion of the Intel
>> > > > >> > GPU config space (offset 0xfc).
>> > > > >> >
>> > > > >> > To work correctly this patch needs a change in hvmloader.
>> > > > >> >
>> > > > >> > HVMloader will allocate 2 pages for the OpRegion and write this address
>> > > > >> > on the config space of the Intel GPU. Qemu will trap and map the host
>> > > > >> > OpRegion to the guest. Any write to this offset after that won't have
>> > > > >> > any effect. Any read of this config space offset will return the address
>> > > > >> > in the guest.
>> > > > >> >
>> > > > >> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>> > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
>> > > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
>> > > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
>> > > > >>
>> > > > >> ?? ?? qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
>> > > > >>
>> > > > >> ?? ?? The OpRegion shouldn't be mapped 1:1 because the address in the host
>> > > > >> ?? ?? can't be used in the guest directly.
>> > > > >>
>> > > > >> ?? ?? This patch traps read and write access to the opregion of the Intel
>> > > > >> ?? ?? GPU config space (offset 0xfc).
>> > > > >>
>> > > > >> ?? ?? To work correctly this patch needs a change in hvmloader.
>> > > > >>
>> > > > >> ?? ?? HVMloader will allocate 2 pages for the OpRegion and write this address
>> > > > >> ?? ?? on the config space of the Intel GPU. Qemu will trap and map the host
>> > > > >> ?? ?? OpRegion to the guest. Any write to this offset after that won't have
>> > > > >> ?? ?? any effect. Any read of this config space offset will return the address
>> > > > >> ?? ?? in the guest.
>> > > > >>
>> > > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
>> > > > >> index dbe8804..7ee3c61 100644
>> > > > >> --- a/hw/pass-through.c
>> > > > >> +++ b/hw/pass-through.c
>> > > > >> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
>> > > > >> ??static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
>> > > > >> ?? ?? ??struct pt_reg_tbl *cfg_entry,
>> > > > >> ?? ?? ??uint32_t real_offset, uint32_t dev_value, uint32_t *value);
>> > > > >> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
>> > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
>> > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t valid_mask);
>> > > > >> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
>> > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
>> > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
>> > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
>> > > > >>
>> > > > >> ??/* pt_reg_info_tbl declaration
>> > > > >> ?? * - only for emulated register (either a part or whole bit).
>> > > > >> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
>> > > > >> ?? ?? ?? ?? ??.u.dw.write = pt_exp_rom_bar_reg_write,
>> > > > >> ?? ?? ?? ?? ??.u.dw.restore = pt_exp_rom_bar_reg_restore,
>> > > > >> ?? ?? ??},
>> > > > >> + ?? ??/* Intel IGFX OpRegion reg */
>> > > > >> + ?? ??{
>> > > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
>> > > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
>> > > > >> + ?? ?? ?? ??.init_val ?? = 0,
>> > > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
>> > > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
>> > > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
>> > > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
>> > > > >> + ?? ??},
>> > > > >> ?? ?? ??{
>> > > > >> ?? ?? ?? ?? ??.size = 0,
>> > > > >> ?? ?? ??},
>> > > > >> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
>> > > > >> ?? ?? ?? ?? ??.grp_id ?? ?? = 0xFF,
>> > > > >> ?? ?? ?? ?? ??.grp_type ?? = GRP_TYPE_EMU,
>> > > > >> ?? ?? ?? ?? ??.grp_size ?? = 0x40,
>> > > > >> - ?? ?? ?? ??.size_init ??= pt_reg_grp_size_init,
>> > > > >> + ?? ?? ?? ??.size_init ??= pt_reg_grp_header0_size_init,
>> > > > >> ?? ?? ?? ?? ??.emu_reg_tbl= pt_emu_reg_header0_tbl,
>> > > > >> ?? ?? ??},
>> > > > >> ?? ?? ??/* PCI PowerManagement Capability reg group */
>> > > > >> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
>> > > > >> ?? ?? ??return reg->init_val;
>> > > > >> ??}
>> > > > >>
>> > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
>> > > > >> +{
>> > > > >> + ?? ??/*
>> > > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
>> > > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
>> > > > >> + ?? ??** therefore the size should be 0xff.
>> > > > >> + ?? ??*/
>> > > > >> + ?? ??if (igd_passthru)
>> > > > >> + ?? ?? ?? ??return 0xFF;
>> > > > >> + ?? ??return grp_reg->grp_size;
>> > > > >> +}
>> > > > >
>> > > > > Apart from the trivial code style error in the comment above, is this
>> > > > > going to have the unintended side effect of initializing as 0 all the
>> > > > > emulated registers between 0x40 and 0xff, that previously were probably
>> > > > > passed through?
>> > > > >
>> > > >
>> > > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
>> > >
>> > > actually there is a small change in behaviour: before your patch
>> > > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
>> > > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
>> > > reg_grp_entry corresponding to "Header Type0 reg group" and then
>> > > pt_find_reg would return NULL.
>> > > This case seems to be handled correctly and bring to the same results
>> > > in both pt_pci_write_config and pt_pci_read_config.
>> > >
>> > > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
>> > > group" only it if really is part of this group otherwise it should be in
>> > > its own separate group.
>> >
>> > The pci pass through groups have been designed to pass through pci capabilities
>> > from the device. You can't really create a group for something which isn't a pci
>> > capability.
>> >
>> > I have noted the change of behavior but that doesn't have any impact on what we
>> > will return to the guest so I think it fine.
>>
>> in that case, ack
>
> Ian,
>
> Could you apply this patch please?
>
> Jean

On 31 January 2012 14:51, Jean Guyader <jean.guyader@eu.citrix.com> wrote:
>
> On 17/01 04:34, Stefano Stabellini wrote:
> > On Tue, 17 Jan 2012, Jean Guyader wrote:
> > > On 17/01 02:51, Stefano Stabellini wrote:
> > > > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > > > On 12 January 2012 14:34, Stefano Stabellini
> > > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > > > >> On 12/01 12:41, Jean Guyader wrote:
> > > > > >> > The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > > > >> > can't be used in the guest directly.
> > > > > >> >
> > > > > >> > This patch traps read and write access to the opregion of the Intel
> > > > > >> > GPU config space (offset 0xfc).
> > > > > >> >
> > > > > >> > To work correctly this patch needs a change in hvmloader.
> > > > > >> >
> > > > > >> > HVMloader will allocate 2 pages for the OpRegion and write this address
> > > > > >> > on the config space of the Intel GPU. Qemu will trap and map the host
> > > > > >> > OpRegion to the guest. Any write to this offset after that won't have
> > > > > >> > any effect. Any read of this config space offset will return the address
> > > > > >> > in the guest.
> > > > > >> >
> > > > > >> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > > > >>
> > > > > >> ?? ?? qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
> > > > > >>
> > > > > >> ?? ?? The OpRegion shouldn't be mapped 1:1 because the address in the host
> > > > > >> ?? ?? can't be used in the guest directly.
> > > > > >>
> > > > > >> ?? ?? This patch traps read and write access to the opregion of the Intel
> > > > > >> ?? ?? GPU config space (offset 0xfc).
> > > > > >>
> > > > > >> ?? ?? To work correctly this patch needs a change in hvmloader.
> > > > > >>
> > > > > >> ?? ?? HVMloader will allocate 2 pages for the OpRegion and write this address
> > > > > >> ?? ?? on the config space of the Intel GPU. Qemu will trap and map the host
> > > > > >> ?? ?? OpRegion to the guest. Any write to this offset after that won't have
> > > > > >> ?? ?? any effect. Any read of this config space offset will return the address
> > > > > >> ?? ?? in the guest.
> > > > > >>
> > > > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > > > >> index dbe8804..7ee3c61 100644
> > > > > >> --- a/hw/pass-through.c
> > > > > >> +++ b/hw/pass-through.c
> > > > > >> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
> > > > > >> ??static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
> > > > > >> ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > > >> ?? ?? ??uint32_t real_offset, uint32_t dev_value, uint32_t *value);
> > > > > >> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t valid_mask);
> > > > > >> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_tbl *cfg_entry,
> > > > > >> + ?? ?? ?? ??uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
> > > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset);
> > > > > >>
> > > > > >> ??/* pt_reg_info_tbl declaration
> > > > > >> ?? * - only for emulated register (either a part or whole bit).
> > > > > >> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tbl[] = {
> > > > > >> ?? ?? ?? ?? ??.u.dw.write = pt_exp_rom_bar_reg_write,
> > > > > >> ?? ?? ?? ?? ??.u.dw.restore = pt_exp_rom_bar_reg_restore,
> > > > > >> ?? ?? ??},
> > > > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > > > >> + ?? ??{
> > > > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > > > >> + ?? ??},
> > > > > >> ?? ?? ??{
> > > > > >> ?? ?? ?? ?? ??.size = 0,
> > > > > >> ?? ?? ??},
> > > > > >> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_grp_tbl[] = {
> > > > > >> ?? ?? ?? ?? ??.grp_id ?? ?? = 0xFF,
> > > > > >> ?? ?? ?? ?? ??.grp_type ?? = GRP_TYPE_EMU,
> > > > > >> ?? ?? ?? ?? ??.grp_size ?? = 0x40,
> > > > > >> - ?? ?? ?? ??.size_init ??= pt_reg_grp_size_init,
> > > > > >> + ?? ?? ?? ??.size_init ??= pt_reg_grp_header0_size_init,
> > > > > >> ?? ?? ?? ?? ??.emu_reg_tbl= pt_emu_reg_header0_tbl,
> > > > > >> ?? ?? ??},
> > > > > >> ?? ?? ??/* PCI PowerManagement Capability reg group */
> > > > > >> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_dev *ptdev,
> > > > > >> ?? ?? ??return reg->init_val;
> > > > > >> ??}
> > > > > >>
> > > > > >> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
> > > > > >> + ?? ?? ?? ??struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offset)
> > > > > >> +{
> > > > > >> + ?? ??/*
> > > > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > > > >> + ?? ??** therefore the size should be 0xff.
> > > > > >> + ?? ??*/
> > > > > >> + ?? ??if (igd_passthru)
> > > > > >> + ?? ?? ?? ??return 0xFF;
> > > > > >> + ?? ??return grp_reg->grp_size;
> > > > > >> +}
> > > > > >
> > > > > > Apart from the trivial code style error in the comment above, is this
> > > > > > going to have the unintended side effect of initializing as 0 all the
> > > > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > > > passed through?
> > > > > >
> > > > >
> > > > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> > > >
> > > > actually there is a small change in behaviour: before your patch
> > > > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > > > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > > > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > > > pt_find_reg would return NULL.
> > > > This case seems to be handled correctly and bring to the same results
> > > > in both pt_pci_write_config and pt_pci_read_config.
> > > >
> > > > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > > > group" only it if really is part of this group otherwise it should be in
> > > > its own separate group.
> > >
> > > The pci pass through groups have been designed to pass through pci capabilities
> > > from the device. You can't really create a group for something which isn't a pci
> > > capability.
> > >
> > > I have noted the change of behavior but that doesn't have any impact on what we
> > > will return to the guest so I think it fine.
> >
> > in that case, ack
>
> Ian,
>
> Could you apply this patch please?
>

Hi Ian,

I was going through my email and it seems that this patch didn't make
it into qemu-xen-unstable.

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

Thanks,
Jean