From: "Chen, Tiejun" <tiejun.chen@intel.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "mst@redhat.com" <mst@redhat.com>, "Kay, Allen M" <allen.m.kay@intel.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Kelly.Zytaruk@amd.com" <Kelly.Zytaruk@amd.com>, "Zhang, Yang Z" <yang.z.zhang@intel.com>, "anthony@codemonkey.ws" <anthony@codemonkey.ws>, "anthony.perard@citrix.com" <anthony.perard@citrix.com> Subject: Re: [Qemu-devel] [v2][PATCH 8/8] xen, gfx passthrough: add opregion mapping Date: Tue, 20 May 2014 09:24:41 +0000 [thread overview] Message-ID: <CCCF29FA0F52DC4B8E2D1EF38AE07FF7B3590B@SHSMSX101.ccr.corp.intel.com> (raw) In-Reply-To: <alpine.DEB.2.02.1405191245290.14596@kaball.uk.xensource.com> > -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] > Sent: Monday, May 19, 2014 7:54 PM > To: Chen, Tiejun > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > mst@redhat.com; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; > xen-devel@lists.xensource.com; peter.maydell@linaro.org; > anthony@codemonkey.ws; weidong.han@intel.com; Kay, Allen M; > jean.guyader@eu.citrix.com; Zhang, Yang Z > Subject: Re: [v2][PATCH 8/8] xen, gfx passthrough: add opregion mapping > > On Fri, 16 May 2014, Tiejun Chen 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). > > > > The original patch is from Jean Guyader <jean.guyader@eu.citrix.com> > > > > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> > > Signed-off-by: Tiejun Chen <tiejun.chen@intel.com> > > Cc: Jean Guyader <jean.guyader@eu.citrix.com> > > --- > > v2: > > > > * We should return zero as an invalid address value while calling > > igd_read_opregion(). > > > > hw/xen/xen_pt.h | 4 +++- > > hw/xen/xen_pt_config_init.c | 45 > ++++++++++++++++++++++++++++++++++++++++++- > > hw/xen/xen_pt_graphics.c | 47 > +++++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 94 insertions(+), 2 deletions(-) > > > > diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index 507165c..25147cf > > 100644 > > --- a/hw/xen/xen_pt.h > > +++ b/hw/xen/xen_pt.h > > @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read) #define > > XEN_PT_BAR_UNMAPPED (-1) > > > > #define PCI_CAP_MAX 48 > > - > > +#define PCI_INTEL_OPREGION 0xfc > > > > typedef enum { > > XEN_PT_GRP_TYPE_HARDWIRED = 0, /* 0 Hardwired reg group */ > @@ > > -306,5 +306,7 @@ int pci_create_pch(PCIBus *bus); 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(XenPCIPassthroughState *s); void > > +igd_write_opregion(XenPCIPassthroughState *s, uint32_t val); > > > > #endif /* !XEN_PT_H */ > > diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c > > index de9a20f..cf36a40 100644 > > --- a/hw/xen/xen_pt_config_init.c > > +++ b/hw/xen/xen_pt_config_init.c > > @@ -575,6 +575,22 @@ static int > xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s, > > return 0; > > } > > > > +static int xen_pt_intel_opregion_read(XenPCIPassthroughState *s, > > + XenPTReg *cfg_entry, > > + uint32_t *value, uint32_t > > +valid_mask) { > > + *value = igd_read_opregion(s); > > + return 0; > > +} > > + > > +static int xen_pt_intel_opregion_write(XenPCIPassthroughState *s, > > + XenPTReg *cfg_entry, > uint32_t *value, > > + uint32_t dev_value, > uint32_t > > +valid_mask) { > > + igd_write_opregion(s, *value); > > + return 0; > > +} > > + > > /* Header Type0 reg static information table */ static XenPTRegInfo > > xen_pt_emu_reg_header0[] = { > > /* Vendor ID reg */ > > @@ -1440,6 +1456,20 @@ static XenPTRegInfo xen_pt_emu_reg_msix[] = { > > }, > > }; > > > > +static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = { > > + /* Intel IGFX OpRegion reg */ > > + { > > + .offset = 0x0, > > + .size = 4, > > + .init_val = 0, > > + .no_wb = 1, > > + .u.dw.read = xen_pt_intel_opregion_read, > > + .u.dw.write = xen_pt_intel_opregion_write, > > + }, > > + { > > + .size = 0, > > + }, > > +}; > > > > /**************************** > > * Capabilities > > @@ -1677,6 +1707,14 @@ static const XenPTRegGroupInfo > xen_pt_emu_reg_grps[] = { > > .size_init = xen_pt_msix_size_init, > > .emu_regs = xen_pt_emu_reg_msix, > > }, > > + /* Intel IGD Opregion group */ > > + { > > + .grp_id = PCI_INTEL_OPREGION, > > + .grp_type = XEN_PT_GRP_TYPE_EMU, > > + .grp_size = 0x4, > > + .size_init = xen_pt_reg_grp_size_init, > > + .emu_regs = xen_pt_emu_reg_igd_opregion, > > + }, > > { > > .grp_size = 0, > > }, > > If I am not mistaken, in the original patch to qemu-xen-traditional, we were not > adding an Intel IGD Opregion group. Instead we were changing the size of the > header Type0 reg group: > > +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; > +} > > Here instead we are adding the new group and forcing the offset to be > PCI_INTEL_OPREGION, below. It looks functionally equivalent, but nicer. > > But wouldn't it be even better to have find_cap_offset return the right offset > for Intel IGD Opregion group? Why do we need to manually set reg_grp_offset > to PCI_INTEL_OPREGION? > > > > > @@ -1806,7 +1844,8 @@ int xen_pt_config_init(XenPCIPassthroughState > *s) > > uint32_t reg_grp_offset = 0; > > XenPTRegGroup *reg_grp_entry = NULL; > > > > - if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) { > > + if (xen_pt_emu_reg_grps[i].grp_id != 0xFF > > + && xen_pt_emu_reg_grps[i].grp_id != > PCI_INTEL_OPREGION) { Actually in this emulated case we still call find_cap_offset() to get reg_grp_offset. > > if (xen_pt_hide_dev_cap(&s->real_device, > > > xen_pt_emu_reg_grps[i].grp_id)) { > > continue; > > @@ -1819,6 +1858,10 @@ int xen_pt_config_init(XenPCIPassthroughState > *s) > > } > > } > > > > + if (xen_pt_emu_reg_grps[i].grp_id == PCI_INTEL_OPREGION) { > > + reg_grp_offset = PCI_INTEL_OPREGION; > > + } > > + But for this pass through scenario, we have to set 0xfc manually since we need to trap 0xfc completely in that comment: + /* + ** 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. + */ Thanks Tiejun
WARNING: multiple messages have this Message-ID (diff)
From: "Chen, Tiejun" <tiejun.chen@intel.com> To: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "mst@redhat.com" <mst@redhat.com>, "Kay, Allen M" <allen.m.kay@intel.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Kelly.Zytaruk@amd.com" <Kelly.Zytaruk@amd.com>, "Zhang, Yang Z" <yang.z.zhang@intel.com>, "anthony@codemonkey.ws" <anthony@codemonkey.ws>, "anthony.perard@citrix.com" <anthony.perard@citrix.com> Subject: Re: [v2][PATCH 8/8] xen, gfx passthrough: add opregion mapping Date: Tue, 20 May 2014 09:24:41 +0000 [thread overview] Message-ID: <CCCF29FA0F52DC4B8E2D1EF38AE07FF7B3590B@SHSMSX101.ccr.corp.intel.com> (raw) In-Reply-To: <alpine.DEB.2.02.1405191245290.14596@kaball.uk.xensource.com> > -----Original Message----- > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] > Sent: Monday, May 19, 2014 7:54 PM > To: Chen, Tiejun > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > mst@redhat.com; Kelly.Zytaruk@amd.com; qemu-devel@nongnu.org; > xen-devel@lists.xensource.com; peter.maydell@linaro.org; > anthony@codemonkey.ws; weidong.han@intel.com; Kay, Allen M; > jean.guyader@eu.citrix.com; Zhang, Yang Z > Subject: Re: [v2][PATCH 8/8] xen, gfx passthrough: add opregion mapping > > On Fri, 16 May 2014, Tiejun Chen 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). > > > > The original patch is from Jean Guyader <jean.guyader@eu.citrix.com> > > > > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> > > Signed-off-by: Tiejun Chen <tiejun.chen@intel.com> > > Cc: Jean Guyader <jean.guyader@eu.citrix.com> > > --- > > v2: > > > > * We should return zero as an invalid address value while calling > > igd_read_opregion(). > > > > hw/xen/xen_pt.h | 4 +++- > > hw/xen/xen_pt_config_init.c | 45 > ++++++++++++++++++++++++++++++++++++++++++- > > hw/xen/xen_pt_graphics.c | 47 > +++++++++++++++++++++++++++++++++++++++++++++ > > 3 files changed, 94 insertions(+), 2 deletions(-) > > > > diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index 507165c..25147cf > > 100644 > > --- a/hw/xen/xen_pt.h > > +++ b/hw/xen/xen_pt.h > > @@ -63,7 +63,7 @@ typedef int (*xen_pt_conf_byte_read) #define > > XEN_PT_BAR_UNMAPPED (-1) > > > > #define PCI_CAP_MAX 48 > > - > > +#define PCI_INTEL_OPREGION 0xfc > > > > typedef enum { > > XEN_PT_GRP_TYPE_HARDWIRED = 0, /* 0 Hardwired reg group */ > @@ > > -306,5 +306,7 @@ int pci_create_pch(PCIBus *bus); 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(XenPCIPassthroughState *s); void > > +igd_write_opregion(XenPCIPassthroughState *s, uint32_t val); > > > > #endif /* !XEN_PT_H */ > > diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c > > index de9a20f..cf36a40 100644 > > --- a/hw/xen/xen_pt_config_init.c > > +++ b/hw/xen/xen_pt_config_init.c > > @@ -575,6 +575,22 @@ static int > xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s, > > return 0; > > } > > > > +static int xen_pt_intel_opregion_read(XenPCIPassthroughState *s, > > + XenPTReg *cfg_entry, > > + uint32_t *value, uint32_t > > +valid_mask) { > > + *value = igd_read_opregion(s); > > + return 0; > > +} > > + > > +static int xen_pt_intel_opregion_write(XenPCIPassthroughState *s, > > + XenPTReg *cfg_entry, > uint32_t *value, > > + uint32_t dev_value, > uint32_t > > +valid_mask) { > > + igd_write_opregion(s, *value); > > + return 0; > > +} > > + > > /* Header Type0 reg static information table */ static XenPTRegInfo > > xen_pt_emu_reg_header0[] = { > > /* Vendor ID reg */ > > @@ -1440,6 +1456,20 @@ static XenPTRegInfo xen_pt_emu_reg_msix[] = { > > }, > > }; > > > > +static XenPTRegInfo xen_pt_emu_reg_igd_opregion[] = { > > + /* Intel IGFX OpRegion reg */ > > + { > > + .offset = 0x0, > > + .size = 4, > > + .init_val = 0, > > + .no_wb = 1, > > + .u.dw.read = xen_pt_intel_opregion_read, > > + .u.dw.write = xen_pt_intel_opregion_write, > > + }, > > + { > > + .size = 0, > > + }, > > +}; > > > > /**************************** > > * Capabilities > > @@ -1677,6 +1707,14 @@ static const XenPTRegGroupInfo > xen_pt_emu_reg_grps[] = { > > .size_init = xen_pt_msix_size_init, > > .emu_regs = xen_pt_emu_reg_msix, > > }, > > + /* Intel IGD Opregion group */ > > + { > > + .grp_id = PCI_INTEL_OPREGION, > > + .grp_type = XEN_PT_GRP_TYPE_EMU, > > + .grp_size = 0x4, > > + .size_init = xen_pt_reg_grp_size_init, > > + .emu_regs = xen_pt_emu_reg_igd_opregion, > > + }, > > { > > .grp_size = 0, > > }, > > If I am not mistaken, in the original patch to qemu-xen-traditional, we were not > adding an Intel IGD Opregion group. Instead we were changing the size of the > header Type0 reg group: > > +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; > +} > > Here instead we are adding the new group and forcing the offset to be > PCI_INTEL_OPREGION, below. It looks functionally equivalent, but nicer. > > But wouldn't it be even better to have find_cap_offset return the right offset > for Intel IGD Opregion group? Why do we need to manually set reg_grp_offset > to PCI_INTEL_OPREGION? > > > > > @@ -1806,7 +1844,8 @@ int xen_pt_config_init(XenPCIPassthroughState > *s) > > uint32_t reg_grp_offset = 0; > > XenPTRegGroup *reg_grp_entry = NULL; > > > > - if (xen_pt_emu_reg_grps[i].grp_id != 0xFF) { > > + if (xen_pt_emu_reg_grps[i].grp_id != 0xFF > > + && xen_pt_emu_reg_grps[i].grp_id != > PCI_INTEL_OPREGION) { Actually in this emulated case we still call find_cap_offset() to get reg_grp_offset. > > if (xen_pt_hide_dev_cap(&s->real_device, > > > xen_pt_emu_reg_grps[i].grp_id)) { > > continue; > > @@ -1819,6 +1858,10 @@ int xen_pt_config_init(XenPCIPassthroughState > *s) > > } > > } > > > > + if (xen_pt_emu_reg_grps[i].grp_id == PCI_INTEL_OPREGION) { > > + reg_grp_offset = PCI_INTEL_OPREGION; > > + } > > + But for this pass through scenario, we have to set 0xfc manually since we need to trap 0xfc completely in that comment: + /* + ** 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. + */ Thanks Tiejun
next prev parent reply other threads:[~2014-05-20 9:25 UTC|newest] Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-05-16 10:53 [Qemu-devel] [v2][PATCH 0/8] xen: add Intel IGD passthrough support Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 1/8] pci: use bitmap to manage registe/runregister pci device Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 2/8] pci: provide a way to reserve some specific devfn Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 14:07 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk 2014-05-16 14:07 ` Konrad Rzeszutek Wilk 2014-05-19 9:43 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 9:43 ` Chen, Tiejun 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 3/8] xen, gfx passthrough: basic graphics passthrough support Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 14:06 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk 2014-05-16 14:06 ` Konrad Rzeszutek Wilk 2014-05-19 9:42 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 9:42 ` Chen, Tiejun 2014-05-19 13:35 ` [Qemu-devel] " Konrad Rzeszutek Wilk 2014-05-19 13:35 ` Konrad Rzeszutek Wilk 2014-05-20 9:32 ` [Qemu-devel] " Chen, Tiejun 2014-05-20 9:32 ` Chen, Tiejun 2014-05-19 12:10 ` [Qemu-devel] " Stefano Stabellini 2014-05-19 12:10 ` Stefano Stabellini 2014-05-20 5:09 ` [Qemu-devel] " Chen, Tiejun 2014-05-20 5:09 ` Chen, Tiejun 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 for INTEL IGD Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 14:08 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk 2014-05-16 14:08 ` Konrad Rzeszutek Wilk 2014-05-19 9:54 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 9:54 ` Chen, Tiejun 2014-05-19 6:44 ` [Qemu-devel] " Gerd Hoffmann 2014-05-19 6:44 ` Gerd Hoffmann 2014-05-19 7:48 ` [Qemu-devel] [Xen-devel] " Fabio Fantoni 2014-05-19 7:48 ` Fabio Fantoni 2014-05-19 8:15 ` [Qemu-devel] " Zhang, Yang Z 2014-05-19 8:15 ` Zhang, Yang Z 2014-05-19 9:34 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 9:34 ` Chen, Tiejun 2014-05-19 9:25 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 9:25 ` Chen, Tiejun 2014-05-19 10:13 ` [Qemu-devel] " Michael S. Tsirkin 2014-05-19 10:13 ` Michael S. Tsirkin 2014-05-20 9:34 ` [Qemu-devel] " Chen, Tiejun 2014-05-20 9:34 ` Chen, Tiejun 2014-05-20 11:36 ` [Qemu-devel] " Michael S. Tsirkin 2014-05-20 11:36 ` Michael S. Tsirkin 2014-05-19 11:22 ` [Qemu-devel] " Gerd Hoffmann 2014-05-19 11:22 ` Gerd Hoffmann 2014-05-19 12:04 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 12:04 ` Chen, Tiejun 2014-05-19 13:50 ` [Qemu-devel] " Gerd Hoffmann 2014-05-19 13:50 ` Gerd Hoffmann 2014-05-19 14:00 ` [Qemu-devel] " Daniel P. Berrange 2014-05-19 14:00 ` Daniel P. Berrange 2014-05-21 7:07 ` [Qemu-devel] " Chen, Tiejun 2014-05-21 7:07 ` Chen, Tiejun 2014-05-22 0:31 ` [Qemu-devel] " Chen, Tiejun 2014-05-22 0:31 ` Chen, Tiejun 2014-05-22 5:39 ` [Qemu-devel] " Gerd Hoffmann 2014-05-22 5:39 ` Gerd Hoffmann 2014-05-22 6:18 ` [Qemu-devel] " Chen, Tiejun 2014-05-22 6:18 ` Chen, Tiejun 2014-05-22 6:44 ` [Qemu-devel] " Gerd Hoffmann 2014-05-22 6:44 ` Gerd Hoffmann 2014-05-22 6:49 ` [Qemu-devel] " Michael S. Tsirkin 2014-05-22 6:49 ` Michael S. Tsirkin 2014-05-22 7:11 ` [Qemu-devel] " Chen, Tiejun 2014-05-22 7:11 ` Chen, Tiejun 2014-05-22 10:50 ` [Qemu-devel] " Chen, Tiejun 2014-05-22 10:50 ` Chen, Tiejun 2014-05-22 11:03 ` [Qemu-devel] " Gonglei (Arei) 2014-05-22 11:03 ` Gonglei (Arei) 2014-05-22 11:22 ` [Qemu-devel] " Gerd Hoffmann 2014-05-22 11:22 ` Gerd Hoffmann 2014-05-23 1:07 ` Chen, Tiejun 2014-05-23 1:07 ` Chen, Tiejun 2014-05-22 11:25 ` [Qemu-devel] " Michael S. Tsirkin 2014-05-22 11:25 ` Michael S. Tsirkin 2014-05-22 14:20 ` [Qemu-devel] [Xen-devel] " Igor Mammedov 2014-05-22 14:20 ` Igor Mammedov 2014-05-23 1:18 ` [Qemu-devel] " Chen, Tiejun 2014-05-23 1:18 ` Chen, Tiejun 2014-05-23 7:38 ` [Qemu-devel] " Igor Mammedov 2014-05-23 7:38 ` Igor Mammedov 2014-05-23 10:52 ` [Qemu-devel] " Anthony PERARD 2014-05-23 10:52 ` Anthony PERARD 2014-05-23 11:40 ` [Qemu-devel] " Stefano Stabellini 2014-05-23 11:40 ` Stefano Stabellini 2014-05-23 11:53 ` [Qemu-devel] " Gerd Hoffmann 2014-05-23 11:53 ` Gerd Hoffmann 2014-05-23 12:06 ` [Qemu-devel] " Igor Mammedov 2014-05-23 12:06 ` Igor Mammedov 2014-05-23 12:16 ` [Qemu-devel] " Igor Mammedov 2014-05-23 12:16 ` Igor Mammedov 2014-05-22 9:58 ` [Qemu-devel] " Konrad Rzeszutek Wilk 2014-05-22 9:58 ` Konrad Rzeszutek Wilk 2014-05-20 14:45 ` [Qemu-devel] " Anthony PERARD 2014-05-20 14:45 ` Anthony PERARD 2014-05-21 1:25 ` [Qemu-devel] " Chen, Tiejun 2014-05-21 1:25 ` Chen, Tiejun 2014-06-25 2:49 ` [Qemu-devel] " Chen, Tiejun 2014-06-25 2:49 ` Chen, Tiejun 2014-06-25 23:04 ` [Qemu-devel] " Slutz, Donald Christopher 2014-06-25 23:04 ` Slutz, Donald Christopher 2014-06-26 2:00 ` [Qemu-devel] " Chen, Tiejun 2014-06-26 2:00 ` Chen, Tiejun 2014-06-26 8:23 ` [Qemu-devel] " Chen, Tiejun 2014-06-26 8:23 ` Chen, Tiejun 2014-06-26 16:58 ` [Qemu-devel] " Don Slutz 2014-06-26 16:58 ` Don Slutz 2014-06-30 9:29 ` [Qemu-devel] " Gerd Hoffmann 2014-06-30 9:29 ` Gerd Hoffmann 2014-06-30 10:23 ` [Qemu-devel] " Chen, Tiejun 2014-06-30 10:23 ` Chen, Tiejun 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 5/8] xen, gfx passthrough: create intel isa bridge Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 14:11 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk 2014-05-16 14:11 ` Konrad Rzeszutek Wilk 2014-05-19 9:59 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 9:59 ` Chen, Tiejun 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 6/8] xen, gfx passthrough: support Intel IGD passthrough with VT-D Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 14:35 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk 2014-05-16 14:35 ` Konrad Rzeszutek Wilk 2014-05-19 0:58 ` [Qemu-devel] " Zhang, Yang Z 2014-05-19 0:58 ` Zhang, Yang Z 2014-05-19 13:34 ` [Qemu-devel] " Konrad Rzeszutek Wilk 2014-05-19 13:34 ` Konrad Rzeszutek Wilk 2014-05-20 5:13 ` [Qemu-devel] " Chen, Tiejun 2014-05-20 5:13 ` Chen, Tiejun 2014-05-20 13:39 ` [Qemu-devel] " Konrad Rzeszutek Wilk 2014-05-20 13:39 ` Konrad Rzeszutek Wilk 2014-05-19 10:02 ` [Qemu-devel] [Xen-devel] " Chen, Tiejun 2014-05-19 10:02 ` Chen, Tiejun 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 7/8] xen, gfx passthrough: create host bridge to passthrough Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-16 14:37 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk 2014-05-16 14:37 ` Konrad Rzeszutek Wilk 2014-05-19 10:03 ` [Qemu-devel] " Chen, Tiejun 2014-05-19 10:03 ` Chen, Tiejun 2014-05-16 10:53 ` [Qemu-devel] [v2][PATCH 8/8] xen, gfx passthrough: add opregion mapping Tiejun Chen 2014-05-16 10:53 ` Tiejun Chen 2014-05-19 11:53 ` [Qemu-devel] " Stefano Stabellini 2014-05-19 11:53 ` Stefano Stabellini 2014-05-20 9:24 ` Chen, Tiejun [this message] 2014-05-20 9:24 ` Chen, Tiejun 2014-05-20 10:50 ` [Qemu-devel] " Stefano Stabellini 2014-05-20 10:50 ` Stefano Stabellini 2014-05-21 0:57 ` [Qemu-devel] " Chen, Tiejun 2014-05-21 0:57 ` Chen, Tiejun
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CCCF29FA0F52DC4B8E2D1EF38AE07FF7B3590B@SHSMSX101.ccr.corp.intel.com \ --to=tiejun.chen@intel.com \ --cc=Kelly.Zytaruk@amd.com \ --cc=allen.m.kay@intel.com \ --cc=anthony.perard@citrix.com \ --cc=anthony@codemonkey.ws \ --cc=mst@redhat.com \ --cc=peter.maydell@linaro.org \ --cc=qemu-devel@nongnu.org \ --cc=stefano.stabellini@eu.citrix.com \ --cc=xen-devel@lists.xensource.com \ --cc=yang.z.zhang@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.