Re: [Xen-users] Q: how to solve "shared RMRR" / "gfn already mapped" / GSI ?

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 14/10/15 12:34, HÃkon Alstadheim wrote:
> Den 14. okt. 2015 12:51, skrev George Dunlap:
>> On Wed, Oct 14, 2015 at 10:32 AM, HÃkon Alstadheim
>> <hakon@xxxxxxxxxxxxxxxxxx> wrote:
>>> Hi all, I'm running xen 4.6.0 since yesterday, and I really appreciate
>>> the progress that is being made, which finally allows me to state my
>>> problem concisely, so an answer /might/ be possible :-) .
>>>
>>> I am trying to pass through a usb-card to a windows domU, and it is not
>>> working. A while ago (well before 4.6) it was working for quite a while,
>>> then it stopped, without me being able to pinpoint what had changed.
>>>
>>> Now, after 4.6 , I have it working for a linux domU, but not for windows
>>> 8.1. Both are identical hvms as much as possible. For the linux domU,
>>> (which is working) xen console says:
>> Since you say it stopped working for Windows "well before 4.6", and it
>> *does* work for Linux with the errors below, I suspect that whatever
>> the problem is has nothing to do with the RMRRs (which are what the
>> errors below are about).
> Well, there are differences, "Direct Vector 0xf3" works, "GSI 28" does not.
> Also forgot I'm using tmem, which may cause a big difference in memory
> layout I guess.
> 
>>
>> You could probably make the errors below go away by adding
>> "mmio_hole=3072" to your config file; but I suspect that your problem
>> will remain.
> Tried the mmio_hole, and the "cannot setup identity map" went away, but
> still no usb for windows.

Right -- well if the warning went away, it means that it *was* able to
set up the identity maps; which means that the RMRRs were set up the way
the device expects them to be.  (That is actually something that would
be different with 4.6; with rdm=relaxed, the warnings were new but the
behavior should have been the same as it has been for ages.)

>> Unfortunately, without a more concrete error message to go on, the
>> most reliable way to find out what caused things to stop working is to
>> do a bisection. :-/
>>
>>
> No upgrades were done to xen or xen-tools at the time it stopped
> working. Could be a windows update, could be some dom0 change. Just
> prior to the failure I had about a month of uptime on the hypervisor,
> with windows domU working all that time. Then usb suddenly gave out
> while the domU was running. A subsequent domU reboot (which also used to
> work OK)  caused a hang on the whole system. I'm afraid I did a BIOS
> update wen the system was down anyway, and that cleared out all the BIOS
> settings :-/ , which I had to recreate from memory.

Ah -- yeah, that makes a bisection pretty much impossible. :-(

Out of curiosity, do you actually need to pass through the entire USB
controller?  Could you pass through just the device itself?

If not, the shortest path to something working may actually be to buy
another controller and see if it works when passed through...

 -George


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