[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.