[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Need help to debug win7 BSOD on IGD passthrough
On Tue, 15 Jan 2013, G.R. wrote: > >> Also, I find that the patch does not work for the linux lspci. > >> It seems to lack of the Caps bit in the status (0x6) register. > >> But according to Ross, that bit only exists in spec 2.1 and becomes > >> reserved in later specs. > >> What do you think? Do we need to provide that bit also? > > > > Being Linux open, you can just clone the code of lspci and see what > > exactly it is looking for. > > Well, I understand that Linux is open. But that's not my question. > Ross's comment gave me the impression that lspci did not adhere to the > standard. > So my question was actually to follow standard or lspci? > > After double checking the spec, it seems that Ross was talking about a > different bit. > The bit that once defined but now reserved is the UDF bit (bit 0x6) in > the Status (ofs 0x6) reg. > While I was talking about the Cap-list (bit 0x4) in the Status (ofs 0x6) reg. > > So it seems that the patch should be fixed to expose this bit and I > need your suggestion here. > Currently I have a quick and dirty hack locally to directly expose > both command (word 0x4) && status (word 0x6) reg. > I'm not sure if it's acceptable (probably not). > I tend to provide read-only access since I have no idea what will > happen if the guest ever try to operate on it (the host bridge > 00:00.0) > I'm not sure if I should expose the Status reg only and exclude > Command reg (in case the Status reg is fully read-only, which I'm not > sure about since I don't have the spec), or just fake a result for > that register. If we choose to fake one, what should the result look > like? I would expose only the Status register, read-only. > PS: it looks that the switch-on-address style of code is not very robust. > This would fail if the guest access using unexpected alignment && length. > I guess may be we should switch to a mask based implementation. Given the way QEMU emulates the PCI config space, I don't think is possible to receive a reads or writes with a length different from 1, 2 or 4 bytes. However I am always open to code improvements. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |