[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops
On 09/17/2015 05:10 AM, Andrew Cooper wrote: On 17/09/15 00:33, Andy Lutomirski wrote:Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently turns all rdmsr and wrmsr operations into the safe variants without any checks that the operations actually succeed. This is IMO awful: it papers over bugs. In particular, KVM gueests might be unwittingly depending on this behavior because CONFIG_KVM_GUEST currently depends on CONFIG_PARAVIRT. I'm not aware of any such problems, but applying this series would be a good way to shake them out. Fix it so that the MSR operations work the same on CONFIG_PARAVIRT=n and CONFIG_PARAVIRT=y as long as Xen isn't being used. The Xen maintainers are welcome to make a similar change on top of this.The Xen side of things need some further modification before this would be a safe operation to perform. On the wrmsr side of things alone, this is the list of things Xen currently objects to and injects #GP faults for. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0bffff000 to 0xffffffff81560060. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff81558100. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff8300ac0f7fc0 to 0x0000000000000000. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d08023fd50 to 0xffffffff815616d0. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0bffff020 to 0xffffffff81561910. (XEN) traps.c:2692:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. However, it would be certainly be worth teaching PVops not to play with MSRs it doesn't own. PVops already knows about those. There is even has a comment about how we shouldn't touch those MSRs. And yet three lines later we still write them. -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |