qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v3 0/9] vfio: capability chains, sparse mmap


From: Alex Williamson
Subject: Re: [Qemu-devel] [RFC PATCH v3 0/9] vfio: capability chains, sparse mmap, device specific regions, IGD support
Date: Wed, 17 Feb 2016 07:02:22 -0700

On Wed, 17 Feb 2016 11:16:37 +0000
"Tian, Kevin" <address@hidden> wrote:

> > From: Alex Williamson
> > Sent: Wednesday, February 17, 2016 5:32 AM
> > 
> > v3:  
> 
> Alex, thanks a lot for your enhancement, which should make future
> vgpu work easier!

Yes, there are a number of vGPU enablers in this series, sparse mmaps
and device specific regions.
 
> > Quite a bit of restructuring, functional differences include exposing
> > another fw_cfg file to indicate the size of the stolen memory region.
> > We really have no need to copy anything into stolen memory, so while
> > we tell SeaBIOS about it via a fw_cfg file, the data pointer is NULL
> > so it can't be read.
> > 
> > I'm also now reading the GGMS size from the GMCH register which
> > determines the size of the GTT region of stolen memory.  The vBIOS
> > is typically only using 1MB, but this is often 2MB in hardware.  I
> > also give the user the ability to specify a GMS value for further
> > stolen memory.  We default it to zero and it's an experimental option
> > so we can remove if it's not useful.  QEMU now does the virtualization
> > of the GMCH and BDSM registers, which is was sort of doing before
> > anyway, but vfio kernel no longer does anything special for them.
> > Getting the GGMS size requires that we know something about the IGD
> > version we're using, so code added for that.  
> 
> I'm not sure how useful keeping stolen memory is. Stolen memory
> is not accessed by CPU directly. One is for GTT, but GTT is alias in
> PCI bar already. The other is to back as framebuffer for early boot-up,
> which is mapped to GTT, so the access actually comes from GPU which
> is what RMRR should care about for IOMMU setup.

I explained the reason why we need stolen memory in reply to the
seabios patch, the vBIOS needs GTT space therefore we need stolen
memory allocated somewhere for the VM so that we can redirect to that
rather than the host stolen memory address space.  Allowing the user to
specify a GMS size may not be useful, but note this in the GPU spec:

    BIOS Requirement: BIOS must not set this bit to 0 [IVD] if the GMS
    field bits 7:3 of this register pre-allocates no memory.

This is a requirement of the VGA disable bit in the MGGC register.
We expose this bit unmodified from hardware, which will almost always
have VGA enabled and therefore expose this bit as zero.  Therefore it's
not legal per the spec to expose GMS as zero with VGA enabled.  I don't
know of anything that requires this, but I left the option open in case
we find something.  Thanks,

Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]