Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1226577 > unrolled thread
| Started by | Andy Lutomirski <luto@kernel.org> |
|---|---|
| First post | 2015-09-17 01:40 +0200 |
| Last post | 2015-09-17 17:20 +0200 |
| Articles | 5 on this page of 25 — 10 participants |
Back to article view | Back to linux.kernel
[PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Andy Lutomirski <luto@kernel.org> - 2015-09-17 01:40 +0200
[PATCH 3/3] x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y Andy Lutomirski <luto@kernel.org> - 2015-09-17 01:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Ingo Molnar <mingo@kernel.org> - 2015-09-17 09:20 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Borislav Petkov <bp@alien8.de> - 2015-09-17 11:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops "H. Peter Anvin" <hpa@zytor.com> - 2015-09-17 13:30 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Paolo Bonzini <pbonzini@redhat.com> - 2015-09-17 13:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Borislav Petkov <bp@alien8.de> - 2015-09-17 17:30 +0200
Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Borislav Petkov <bp@alien8.de> - 2015-09-17 17:40 +0200
Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Andrew Cooper <andrew.cooper3@citrix.com> - 2015-09-17 17:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Arjan van de Ven <arjan@linux.intel.com> - 2015-09-17 17:30 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Paolo Bonzini <pbonzini@redhat.com> - 2015-09-17 17:30 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Arjan van de Ven <arjan@linux.intel.com> - 2015-09-17 17:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Paolo Bonzini <pbonzini@redhat.com> - 2015-09-17 17:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Andy Lutomirski <luto@amacapital.net> - 2015-09-17 17:30 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Ingo Molnar <mingo@kernel.org> - 2015-09-17 19:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Andy Lutomirski <luto@amacapital.net> - 2015-09-17 21:00 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Peter Zijlstra <peterz@infradead.org> - 2015-09-17 11:10 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Paolo Bonzini <pbonzini@redhat.com> - 2015-09-17 13:50 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Peter Zijlstra <peterz@infradead.org> - 2015-09-17 14:40 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Andy Lutomirski <luto@amacapital.net> - 2015-09-17 17:20 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Peter Zijlstra <peterz@infradead.org> - 2015-09-17 17:30 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Andy Lutomirski <luto@amacapital.net> - 2015-09-17 17:30 +0200
Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Paolo Bonzini <pbonzini@redhat.com> - 2015-09-17 17:40 +0200
Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Andrew Cooper <andrew.cooper3@citrix.com> - 2015-09-17 11:20 +0200
Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2015-09-17 17:20 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-09-17 17:30 +0200 |
| Message-ID | <q9Jii-7CU-13@gated-at.bofh.it> |
| In reply to | #1227105 |
On Thu, Sep 17, 2015 at 08:17:18AM -0700, Andy Lutomirski wrote: > > Ah, that would be good news. Andy earlier argued I could not rely on > > rdmsr_safe() faulting on unknown MSRs. If practically we can there's > > some code I can simplify :-) > > I was taking about QEMU TCG, not KVM. Just for my education, TCG is the thing without _any_ hardware assist? The thing you fear to use because it cannot boot a kernel this side of tomorrow etc.. ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-09-17 17:30 +0200 |
| Message-ID | <q9Jii-7CU-25@gated-at.bofh.it> |
| In reply to | #1227121 |
On Thu, Sep 17, 2015 at 8:17 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Thu, Sep 17, 2015 at 08:17:18AM -0700, Andy Lutomirski wrote: > >> > Ah, that would be good news. Andy earlier argued I could not rely on >> > rdmsr_safe() faulting on unknown MSRs. If practically we can there's >> > some code I can simplify :-) >> >> I was taking about QEMU TCG, not KVM. > > Just for my education, TCG is the thing without _any_ hardware assist? Yes. > The thing you fear to use because it cannot boot a kernel this side of > tomorrow etc.. ? I actually use it on a semi-regular basis. It appears to boot a normal kernel correctly and surprisingly quickly. It's important for a silly reason. Asking KVM on an Intel host to emulate an AMD CPU or vice versa results in a chimera: I get an Opteron that's "GenuineIntel", which causes Linux to treat it as Intel, which means it gets the Intel quirks (SYSENTER in long mode, no X86_BUG_SYSRET_SS_ATTRS, etc) instead of the AMD quirks (SYSCALL in compat mode, etc). So, if I want to test compat SYSCALL, I have to use TCG, which will actually do a decent job of emulating an AMD CPU for me. Maybe Paolo can fix QEMU to fail bad MSR accesses for real... --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Date | 2015-09-17 17:40 +0200 |
| Message-ID | <q9JrZ-7OO-43@gated-at.bofh.it> |
| In reply to | #1227125 |
On 17/09/2015 17:26, Andy Lutomirski wrote: > Maybe Paolo can fix QEMU to fail bad MSR accesses for real... I was afraid of someone proposing exactly that. :) I can do it since the list of MSRs can be lifted from KVM. Let's first see the direction these patches go... Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Cooper <andrew.cooper3@citrix.com> |
|---|---|
| Date | 2015-09-17 11:20 +0200 |
| Subject | Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops |
| Message-ID | <q9Dwe-7Az-11@gated-at.bofh.it> |
| In reply to | #1226577 |
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. ~Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2015-09-17 17:20 +0200 |
| Subject | Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops |
| Message-ID | <q9J8C-7rl-3@gated-at.bofh.it> |
| In reply to | #1226791 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web