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: Sunday, December 23, 2012 1:11 AM
> To: Ross Philipson
> Cc: xen-devel; Keir (Xen.org); Ian Campbell; Jean.guyader@xxxxxxxxx;
> Stefano Stabellini
> Subject: Re: [Xen-devel] [PATCH] hvmloader / qemu-xen: Getting rid of
> resource conflict for OpRegion.
> 
> On Sat, Dec 22, 2012 at 1:26 AM, Ross Philipson
> <Ross.Philipson@xxxxxxxxxx> wrote:
> >> > 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.
> 
> So you are able to get a working win7 domU with IGD passthrough? That's
> amazing.
> Currently I just have a working linux domU with IGD passthrough. (just
> solve the last known functionality issue)
> But the win7 domU keeps BSOD during early boot stage with IGD passed
> through.
> The BSOD varies time to time, with or without intel gfx driver
> installed.
> But all the BSODs are more or less related to memory corruption.
> I begun to suspect this may have something to do with the bios /
> firmware.
> (Your working system are based on intel board, right? Mine are Asrock
> H77m-itx)
> But I don't have enough knowledge to triage the issue (all I can do so
> far is to analyze core dump with KDB).

Hmm, I found a similar issue with BSODs like this and I tacked it down to the 
Windows igfx drivers expecting to find vendor capabilities in the GMCH device 
(the root device at 00:00.0). It was actually looking there for capabilities 
specific to the gfx card. We fixed this by patching qemu to pass in the vendor 
capabilities on that device. I am not sure if that made it upstream - I will 
have to check.

> 
> I'll start a separate thread about this and keep this thread focused.
> Help you could give me some hint in that thread.

What is the separate thread going to be for? I did not see it.

> 
> >> 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.
> >
> 
> Ross, your help is highly appreciated. I think it's not you that
> confused things.
> The problem comes from my side, I'm far from familiar with all these
> ACPI / BIOS related stuff.
> I dumped && disassembled the ACPI table. But have no idea how to read
> the output...
> I attached the DSDT.dsl dumped from my system, in case you would like
> to take a quick check.
> 
> Just one more question -- is the layout specific to the bios, or common?
> I wonder how can we judge the security risk if the layout is not
> constant.

I would say the layout of the IGD stuff is common per the Intel spec for it and 
the OEMs have to follow that spec when writing the BIOS. But it could change 
for newer hardware (with a new rev of the spec for example that extended the 
IGD functionality). 

> 
> 
> > Oh and I forgot to add. In addition there are other OpRegions defined
> like
> > GNVS that can give you an idea of what might be just before and after
> the
> > IGD regions when it is not page aligned.
> 
> Thanks for your hint, I've seen this -- many of these.
> The only issue is that I don't understand what do they mean. :-(
> I think I need to dig into specs when I got spare time.

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