Re: (v2) Design proposal for RMRR fix

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 09/01/15 00:53, Tian, Kevin wrote:
>> From: Tim Deegan [mailto:tim@xen.org]
>> Sent: Thursday, January 08, 2015 8:32 PM
>>
>> Hi Kevin,
>>
>> Thanks for sending out this design document.  I think Jan will have
>> the most to say about this.  Looking just at the hypervisor side of
>> things, and leaving the tools desig to others...
>>
>> At 11:23 +0000 on 26 Dec (1419589382), Tian, Kevin wrote:
>>> c) in Xen hypervisor it is reasonable to fail upon confliction, where
>>> device is actually assigned. But due to the same requirement on USB
>>> controller, sometimes we might want it succeed just w/ warnings.
>> Can you explain more concretely why we would want to allow assignment
>> whn the RMRR setup fails?  It seems like the device's use of the RMRR
>> will (at least) corrupt the OS and (possibly) make the device itself
>> fail.
> For USB device, RMRR is used only in early-boot phase, as a way for
> communication between legacy keyboard driver and bios. That emulation
> mode will be disabled either at some ACPI initialization step or when
> USB keyboard driver is loader (sorry don't remember detail). So when
> it's assigned to a guest, there's no legacy emulation and not setting up
> identity mapping is not a critical issue. If we think such usage case is
> a valid one, 'fail' would cause regression on that.

XenServer has observed OEMs using RMRRs for stats reporting back to the BMC.

It is not safe to assume that a USB device with an RMRR would only ever
be using it for legacy keyboard emulation.  It is also not safe to
assume that legacy keyboard emulation might not resume at some point in
the future, although I would hope that it would not.

Therefore, I feel that USB controllers should not be permitted a special
case compared to other devices.

~Andrew