Re: [Xen-devel] [PATCH] hvmloader / qemu-xen: Getting rid of resource conflict for OpRegion.

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----Original Message-----
> From: firemeteor.guo@xxxxxxxxx [mailto:firemeteor.guo@xxxxxxxxx] On
> Behalf Of G.R.
> Sent: Thursday, December 20, 2012 11:00 PM
> To: Ross Philipson
> Cc: Keir (Xen.org); Stefano Stabellini; Ian Campbell;
> Jean.guyader@xxxxxxxxx; xen-devel
> Subject: Re: [Xen-devel] [PATCH] hvmloader / qemu-xen: Getting rid of
> resource conflict for OpRegion.
> 
> On Fri, Dec 21, 2012 at 2:27 AM, Ross Philipson
> <Ross.Philipson@xxxxxxxxxx> wrote:
> 
> 
> >> > Possibly with suitable macros used instead of magic numbers (e.g.,
> >> > XC_PAGE_* and a macro for the opregion size).
> >>
> >> I guess there is no predefined macro for OpRegion size. And I guess I
> >> need to define it twice for both code?
> >
> > In addition we should think about defining the IGD OpRegion in ACPI
> per the spec (cited earlier). Guest drivers seem to find the region just
> by reading the ASLS register in the gfx device's config space but it
> would be more correct to define it in ACPI too. Just a thought.
> 
> Is it a requirement for the patch to be accepted? Or, are you saying
> that this should not be IGD passthrough specific?
> I'm not sure what you refer to by 'ACPI' here. Is it the spec itself or
> header in your source code?
> I'm sorry to ask but I'm just a unlucky user trying to fix my box.
> 
> The ASLS register is just the documented way to communicate the OpRegion
> you can find in the spec.
> There are a lot of details in the spec. But as long as we are not going
> to emulate it, only the size is relevant here, I believe.

I guess all I am pointing out is that the IGD OpRegion is supposed to be 
defined in ACPI (that is actually why it is called an OpRegion). On all they 
systems I have seen it is in the DSDT (look for IDGP and IGDM). The OpRegion 
declaration actually tells you how big the region is and where its base is. It 
should probably only be there in the case where you are passing in the igfx 
device but this could be done by loading an auxiliary SSDT table. In addition 
to the IGD definition, the BIOSes on these systems also define other NVS 
regions related to graphics which might be useful, at least in determining 
their size and layout.

I have been thinking about this in relationship to our igfx passthrough 
support. We see some odd behaviors here and there with igfx pt and the guest 
drivers (which we have no control over in say the Windows case). I don't 
currently have hard evidence that these missing BIOS bits are causing any 
specific problems but they are an inconsistency wrt to the spec and on my list 
of suspects.

Thanks
Ross


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel