[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: 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |