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

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



> -----Original Message-----
> From: firemeteor.guo@xxxxxxxxx [mailto:firemeteor.guo@xxxxxxxxx] On
> Behalf Of G.R.
> Sent: Friday, December 21, 2012 11:49 AM
> 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.
> 
> >> >> 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.
> 
> Great! So you are the expert about these firmwares. I also tried to grep
> in these ACPI tables but did not found anything useful.
> I can see that IGDM has a matching size, but the base refers to an entry
> called 'ASLB', which is not directly visible from the dump.

ASLB is a field in another OpRegion that defines other areas of the gfx
related NVS regions. So the value will be present at runtime and you can
query it via the ACPI object. But the same value should be reported in
the ASLS register in the PCI config space for the igfx device which is a
lot easier to get at.

> 
> The intel opregion spec gives me the impression that it's part of the
> ACPI spec. And you are saying that is is not! What a astonishing news to
> me.

I think the spec is saying that the IGD OpRegion should be defined in ACPI
using standard ACPI entities like OpRegions and Fields.

> 
> > 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.
> 
> Yes, my win 7 guest is totally broken with IGD passthrough (much worse
> than linux status).
> Before I bought my current build, sources like wikis seems to mention
> that IGD is the first card that works.
> And now, it seems the AMD cards are the best choice for pass-through.
> Sad news for me.

Let me just clarify that up to now we have been successful in passing in
igfx cards without having to surface any of these ACPI bits. I was just
mentioning that this is an inconsistency and might be worth investigating
at some point. More importantly I am pointing out that if you are trying
to find out information like the location/size/layout of the IGD OpRegion,
you can get that information from the host BIOS. That sounded like what
your original issues centered around. Sorry if I confused things.

> 
> Thanks,
> Timothy

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


 


Rackspace

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