Han, Weidong
2010-Feb-04 08:12 UTC
[Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough
Some registers of Intel IGD are mapped in host bridge, so it needs to passthrough these registers of physical host bridge to guest because emulated host bridge in guest doesn''t have these mappings. Some VBIOSs and drivers ssume the IGD BDF (bus:device:function) is always 00:02.0, so this patch reserves 00:02.0 for assigned IGD in guest. Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2010-Feb-04 17:08 UTC
Re: [Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough
Han, Weidong writes ("[Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough "):> Some registers of Intel IGD are mapped in host bridge, so it needs > to passthrough these registers of physical host bridge to guest > because emulated host bridge in guest doesn''t have these mappings. > > Some VBIOSs and drivers ssume the IGD BDF (bus:device:function) is > always 00:02.0, so this patch reserves 00:02.0 for assigned IGD in > guest.Thanks for the contribution, which I have applied with a very small change to avoid having an open else at #endif. However the part in pci.c is really very ugly indeed. If we ever get around to rebasing to recent upstream qemu and trying to upstream our patches, this is sure to be dropped. So you might profitably spend some time thinking how to make it less ugly. Thanks, Ian.> +#ifdef CONFIG_PASSTHROUGH > + /* host bridge reads for IGD passthrough */ > + if ( igd_passthru && pci_dev->devfn == 0x00 ) > + { > + val = pci_dev->config_read(pci_dev, config_addr, len); > + > + if ( config_addr == 0x00 && len == 4 ) > + val = pt_pci_host_read_long(0, 0, 0, 0x00); > + else if ( config_addr == 0x02 ) // Device ID > + val = pt_pci_host_read_word(0, 0, 0, 0x02); > + else if ( config_addr == 0x52 ) // GMCH Graphics Control Register > + val = pt_pci_host_read_word(0, 0, 0, 0x52); > + else if ( config_addr == 0xa0 ) // GMCH Top of Memory Register > + val = pt_pci_host_read_word(0, 0, 0, 0xa0); > + } > + else if ( igd_passthru && pci_dev->devfn == 0x10 && > + config_addr == 0xfc ) // read on IGD device > + val = 0; // use SMI to communicate with the system BIOS > + else > +#endif > + val = pci_dev->config_read(pci_dev, config_addr, len); > +_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Feb-05 01:52 UTC
Re: [Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough
Ian Jackson wrote:> Han, Weidong writes ("[Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough "): > >> Some registers of Intel IGD are mapped in host bridge, so it needs >> to passthrough these registers of physical host bridge to guest >> because emulated host bridge in guest doesn''t have these mappings. >> >> Some VBIOSs and drivers ssume the IGD BDF (bus:device:function) is >> always 00:02.0, so this patch reserves 00:02.0 for assigned IGD in >> guest. >> > > Thanks for the contribution, which I have applied with a very small > change to avoid having an open else at #endif. > > However the part in pci.c is really very ugly indeed. If we ever get > around to rebasing to recent upstream qemu and trying to upstream our > patches, this is sure to be dropped. So you might profitably spend > some time thinking how to make it less ugly. > > Thanks, > Ian. >Thanks for check-in. I agree the hacking in pci.c is not elegant. We will think how to make it cleaner. Regards, Weidong> >> +#ifdef CONFIG_PASSTHROUGH >> + /* host bridge reads for IGD passthrough */ >> + if ( igd_passthru && pci_dev->devfn == 0x00 ) >> + { >> + val = pci_dev->config_read(pci_dev, config_addr, len); >> + >> + if ( config_addr == 0x00 && len == 4 ) >> + val = pt_pci_host_read_long(0, 0, 0, 0x00); >> + else if ( config_addr == 0x02 ) // Device ID >> + val = pt_pci_host_read_word(0, 0, 0, 0x02); >> + else if ( config_addr == 0x52 ) // GMCH Graphics Control Register >> + val = pt_pci_host_read_word(0, 0, 0, 0x52); >> + else if ( config_addr == 0xa0 ) // GMCH Top of Memory Register >> + val = pt_pci_host_read_word(0, 0, 0, 0xa0); >> + } >> + else if ( igd_passthru && pci_dev->devfn == 0x10 && >> + config_addr == 0xfc ) // read on IGD device >> + val = 0; // use SMI to communicate with the system BIOS >> + else >> +#endif >> + val = pci_dev->config_read(pci_dev, config_addr, len); >> + >>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Isaku Yamahata
2010-Feb-18 09:49 UTC
Re: [Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough
On Fri, Feb 05, 2010 at 09:52:47AM +0800, Weidong Han wrote:> Ian Jackson wrote: >> Han, Weidong writes ("[Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough "): >> >>> Some registers of Intel IGD are mapped in host bridge, so it needs >>> to passthrough these registers of physical host bridge to guest >>> because emulated host bridge in guest doesn''t have these mappings. >>> >>> Some VBIOSs and drivers ssume the IGD BDF (bus:device:function) is >>> always 00:02.0, so this patch reserves 00:02.0 for assigned IGD in >>> guest. >>> >> >> Thanks for the contribution, which I have applied with a very small >> change to avoid having an open else at #endif. >> >> However the part in pci.c is really very ugly indeed. If we ever get >> around to rebasing to recent upstream qemu and trying to upstream our >> patches, this is sure to be dropped. So you might profitably spend >> some time thinking how to make it less ugly. >> >> Thanks, >> Ian. >> > > Thanks for check-in. I agree the hacking in pci.c is not elegant. We > will think how to make it cleaner.This can be moved out as read_config callback. See 400fx_init() calling pci_register_device() in pciix_pci.c and some wrapper of pt_cpi_read_config(). thanks,> > Regards, > Weidong > > >> >>> +#ifdef CONFIG_PASSTHROUGH >>> + /* host bridge reads for IGD passthrough */ >>> + if ( igd_passthru && pci_dev->devfn == 0x00 ) >>> + { >>> + val = pci_dev->config_read(pci_dev, config_addr, len); >>> + >>> + if ( config_addr == 0x00 && len == 4 ) >>> + val = pt_pci_host_read_long(0, 0, 0, 0x00); >>> + else if ( config_addr == 0x02 ) // Device ID >>> + val = pt_pci_host_read_word(0, 0, 0, 0x02); >>> + else if ( config_addr == 0x52 ) // GMCH Graphics Control Register >>> + val = pt_pci_host_read_word(0, 0, 0, 0x52); >>> + else if ( config_addr == 0xa0 ) // GMCH Top of Memory Register >>> + val = pt_pci_host_read_word(0, 0, 0, 0xa0); >>> + } >>> + else if ( igd_passthru && pci_dev->devfn == 0x10 && >>> + config_addr == 0xfc ) // read on IGD device >>> + val = 0; // use SMI to communicate with the system BIOS >>> + else >>> +#endif >>> + val = pci_dev->config_read(pci_dev, config_addr, len); >>> + >>> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- yamahata _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Feb-20 07:47 UTC
Re: [Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough
Isaku Yamahata wrote:> On Fri, Feb 05, 2010 at 09:52:47AM +0800, Weidong Han wrote: > >> Ian Jackson wrote: >> >>> Han, Weidong writes ("[Xen-devel][PATCH 1/3] VT-d: support Intel IGD passthrough "): >>> >>> >>>> Some registers of Intel IGD are mapped in host bridge, so it needs >>>> to passthrough these registers of physical host bridge to guest >>>> because emulated host bridge in guest doesn''t have these mappings. >>>> >>>> Some VBIOSs and drivers ssume the IGD BDF (bus:device:function) is >>>> always 00:02.0, so this patch reserves 00:02.0 for assigned IGD in >>>> guest. >>>> >>>> >>> Thanks for the contribution, which I have applied with a very small >>> change to avoid having an open else at #endif. >>> >>> However the part in pci.c is really very ugly indeed. If we ever get >>> around to rebasing to recent upstream qemu and trying to upstream our >>> patches, this is sure to be dropped. So you might profitably spend >>> some time thinking how to make it less ugly. >>> >>> Thanks, >>> Ian. >>> >>> >> Thanks for check-in. I agree the hacking in pci.c is not elegant. We >> will think how to make it cleaner. >> > > This can be moved out as read_config callback. > See 400fx_init() calling pci_register_device() in pciix_pci.c > and some wrapper of pt_cpi_read_config(). > > thanks, > >Sound reasonable. Regards, Weidong>> Regards, >> Weidong >> >> >> >>> >>> >>>> +#ifdef CONFIG_PASSTHROUGH >>>> + /* host bridge reads for IGD passthrough */ >>>> + if ( igd_passthru && pci_dev->devfn == 0x00 ) >>>> + { >>>> + val = pci_dev->config_read(pci_dev, config_addr, len); >>>> + >>>> + if ( config_addr == 0x00 && len == 4 ) >>>> + val = pt_pci_host_read_long(0, 0, 0, 0x00); >>>> + else if ( config_addr == 0x02 ) // Device ID >>>> + val = pt_pci_host_read_word(0, 0, 0, 0x02); >>>> + else if ( config_addr == 0x52 ) // GMCH Graphics Control Register >>>> + val = pt_pci_host_read_word(0, 0, 0, 0x52); >>>> + else if ( config_addr == 0xa0 ) // GMCH Top of Memory Register >>>> + val = pt_pci_host_read_word(0, 0, 0, 0xa0); >>>> + } >>>> + else if ( igd_passthru && pci_dev->devfn == 0x10 && >>>> + config_addr == 0xfc ) // read on IGD device >>>> + val = 0; // use SMI to communicate with the system BIOS >>>> + else >>>> +#endif >>>> + val = pci_dev->config_read(pci_dev, config_addr, len); >>>> + >>>> >>>> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Timothy J. Moore
2010-Feb-21 23:18 UTC
[Xen-devel] VT-d support proprietary NVidia/ATI GPU passthrough
Dear Xen-developers, Now that we have IGD passthough patches in the xen source tree, would it be possible to start working on support for other vendor cards? I know and have working the necessary patches to enable PCI/VGA Pass-through for non IGD, but it''s a long way from stable - Is there a way that vendor specific resets or FLR code could be implemented that will provide a stable experience when using VGA passthrough with NVidia and plugging/unplugging and starting/rebooting DomUs? Can the vBAR-pBAR code that Wiedong provided be implemented in a more dynamic way? (currently requires static mem ranges) Thanks all, anyone who could help please shout ! Tim _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Feb-22 07:07 UTC
[Xen-devel] Re: VT-d support proprietary NVidia/ATI GPU passthrough
Timothy J. Moore wrote:> Dear Xen-developers, > > Now that we have IGD passthough patches in the xen source tree, would it be possible to start working on support for other vendor cards? >Xen already implemented basic gfx passthrough a few months ago, and supported "virtualization friendly" gfx passthrough, such as nVidia FX3800. But for most discrete GPU, they need various hacks, such as vBAR=pBAR.> I know and have working the necessary patches to enable PCI/VGA Pass-through for non IGD, but it''s a long way from stable - > > Is there a way that vendor specific resets or FLR code could be implemented that will provide a stable experience when using VGA passthrough with NVidia and plugging/unplugging and starting/rebooting DomUs? >yes, FLR is a problem for gfx cards which don''t support standard FLR capability. FLR is required for passthrough, but lots of existing gfx cards don''t have this capability, and only gfx vendors know how to implement vendor specific reset.> Can the vBAR-pBAR code that Wiedong provided be implemented in a more dynamic way? (currently requires static mem ranges) >Yes, the patch is experimental, and not suitable for upstream now. Regards, Weidong> Thanks all, anyone who could help please shout ! > > Tim >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Timothy J. Moore
2010-Feb-22 12:32 UTC
[Xen-devel] RE: VT-d support proprietary NVidia/ATI GPU passthrough
How can xen implement these vendor specific resets? How could we find out the gfx vendor specific stuff? Can we take anything from the opensource NV, nouveau, or Gallium3D drivers? -----Original Message----- From: Weidong Han [mailto:weidong.han@intel.com] Sent: 22 February 2010 07:08 To: Timothy J. Moore Cc: xen-devel@lists.xensource.com Subject: Re: VT-d support proprietary NVidia/ATI GPU passthrough Timothy J. Moore wrote:> Dear Xen-developers, > > Now that we have IGD passthough patches in the xen source tree, would it be possible to start working on support for other vendor cards? >Xen already implemented basic gfx passthrough a few months ago, and supported "virtualization friendly" gfx passthrough, such as nVidia FX3800. But for most discrete GPU, they need various hacks, such as vBAR=pBAR.> I know and have working the necessary patches to enable PCI/VGA Pass-through for non IGD, but it''s a long way from stable - > > Is there a way that vendor specific resets or FLR code could be implemented that will provide a stable experience when using VGA passthrough with NVidia and plugging/unplugging and starting/rebooting DomUs? >yes, FLR is a problem for gfx cards which don''t support standard FLR capability. FLR is required for passthrough, but lots of existing gfx cards don''t have this capability, and only gfx vendors know how to implement vendor specific reset.> Can the vBAR-pBAR code that Wiedong provided be implemented in a more dynamic way? (currently requires static mem ranges) >Yes, the patch is experimental, and not suitable for upstream now. Regards, Weidong> Thanks all, anyone who could help please shout ! > > Tim >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2010-Feb-22 16:48 UTC
Re: [Xen-devel] RE: VT-d support proprietary NVidia/ATI GPU passthrough
On Mon, Feb 22, 2010 at 12:32:48PM +0000, Timothy J. Moore wrote:> How can xen implement these vendor specific resets? How could we find out the gfx vendor specific stuff? > > Can we take anything from the opensource NV, nouveau, or Gallium3D drivers?As I understand it, the reason for the FLR is to re-initialize the video cards to re-run through the basic ROM code. Pretty much exactly the same thing that is done during machine startup. But for gfx pass-through you need to this with the Bochs code running so it can call the gfx BIOS. I don''t think that the open-source drivers go so low to re-initialize the card? Thought perhaps another way to do this, is to put the cards in D3 (cold) state and then re-initialize them back up? (this is btw, what the pciback drivers does when it seizes the card). _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Weidong Han
2010-Feb-23 01:16 UTC
Re: [Xen-devel] RE: VT-d support proprietary NVidia/ATI GPU passthrough
Konrad Rzeszutek Wilk wrote:> On Mon, Feb 22, 2010 at 12:32:48PM +0000, Timothy J. Moore wrote: > >> How can xen implement these vendor specific resets? How could we find out the gfx vendor specific stuff? >> >> Can we take anything from the opensource NV, nouveau, or Gallium3D drivers? >> > > As I understand it, the reason for the FLR is to re-initialize the video > cards to re-run through the basic ROM code. Pretty much exactly the same > thing that is done during machine startup. But for gfx pass-through you > need to this with the Bochs code running so it can call the gfx BIOS. > > I don''t think that the open-source drivers go so low to re-initialize > the card? > > Thought perhaps another way to do this, is to put the cards in D3 (cold) > state and then re-initialize them back up? (this is btw, what the > pciback drivers does when it seizes the card). >reset through Dstate transition is not guarantee to work for all devices. As we observed, it seems didn''t work for Intel IGD, so we implemented vendor specific reset for Intel IGD. Regards, Weidong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Timothy J. Moore
2010-Feb-23 21:08 UTC
RE: [Xen-devel] RE: VT-d support proprietary NVidia/ATI GPU passthrough
I agree, pciback Dstate transition does not seem to work with Nvidia cards either .. Also, I believe XCI attempts Dstate + secondary bus reset + FLR and they don''t work too! Seems to be vendor specific calls that are needed, but where can we obtain this info ? -----Original Message----- From: Weidong Han [mailto:weidong.han@intel.com] Sent: 23 February 2010 01:16 To: Konrad Rzeszutek Wilk Cc: Timothy J. Moore; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] RE: VT-d support proprietary NVidia/ATI GPU passthrough Konrad Rzeszutek Wilk wrote:> On Mon, Feb 22, 2010 at 12:32:48PM +0000, Timothy J. Moore wrote: > >> How can xen implement these vendor specific resets? How could we find out the gfx vendor specific stuff? >> >> Can we take anything from the opensource NV, nouveau, or Gallium3D drivers? >> > > As I understand it, the reason for the FLR is to re-initialize the video > cards to re-run through the basic ROM code. Pretty much exactly the same > thing that is done during machine startup. But for gfx pass-through you > need to this with the Bochs code running so it can call the gfx BIOS. > > I don''t think that the open-source drivers go so low to re-initialize > the card? > > Thought perhaps another way to do this, is to put the cards in D3 (cold) > state and then re-initialize them back up? (this is btw, what the > pciback drivers does when it seizes the card). >reset through Dstate transition is not guarantee to work for all devices. As we observed, it seems didn''t work for Intel IGD, so we implemented vendor specific reset for Intel IGD. Regards, Weidong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel