Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support
On Tue, Nov 01, 2016 at 08:51:57AM +0100, Paul Bolle wrote: > And as probably everybody capable of hacking on lguest (ie, other > people than me) came up with doubts similar to yours, these two issues > never got fixed. You can always try to fix them and see where it gets ya. I think that's the *ultimate* goal of lguest. :-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support
On Tue, 2016-11-01 at 00:48 +0100, Borislav Petkov wrote: > --- a/drivers/lguest/Kconfig > +++ b/drivers/lguest/Kconfig > config LGUEST > tristate "Linux hypervisor example code" > - depends on X86_32 && EVENTFD && TTY && PCI_DIRECT > > + depends on X86_32 && EVENTFD && TTY && PCI_DIRECT && !MICROCODE > select HVC_DRIVER > ---help--- > This is a very simple module which allows you to run LGUEST is the symbol for host support. The symbol for guest support is LGUEST_GUEST and it lives in arch/x86/. Yes, it's a bit of a gotcha. > but maybe the better fix is to hack in MSR emulation in lguest and > intercept the *MSR accesses and do the writes/reads in the exception > fixup and ... > > I haven't looked at the lguest code, of course and whether that's easily > doable and whether it even makes sense and whether one should simply use > qemu/kvm instead and, and, and... Yeah, I thought about adding negative dependencies (eg, "!OLPC && !MICROCODE") too. But that would be contrary to the neat lguest goal to be able to use the same kernel image as a host and a guest. At least, I think that is one of its goals. And as probably everybody capable of hacking on lguest (ie, other people than me) came up with doubts similar to yours, these two issues never got fixed. Thanks, Paul Bolle
Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support
On Tue, Nov 01, 2016 at 12:10:48AM +0100, Paul Bolle wrote: > See https://lists.ozlabs.org/pipermail/lguest/2013-May/002001.html . > Nobody cared enough to fix it. I cared enough to figure it all out. But > I didn't understand much of the possible solutions that where suggested > three years ago. I'm guessing the simple fix would be this: --- diff --git a/drivers/lguest/Kconfig b/drivers/lguest/Kconfig index 169172d2ba05..9c08b3050bb7 100644 --- a/drivers/lguest/Kconfig +++ b/drivers/lguest/Kconfig @@ -1,6 +1,6 @@ config LGUEST tristate "Linux hypervisor example code" - depends on X86_32 && EVENTFD && TTY && PCI_DIRECT + depends on X86_32 && EVENTFD && TTY && PCI_DIRECT && !MICROCODE select HVC_DRIVER ---help--- This is a very simple module which allows you to run --- but maybe the better fix is to hack in MSR emulation in lguest and intercept the *MSR accesses and do the writes/reads in the exception fixup and ... I haven't looked at the lguest code, of course and whether that's easily doable and whether it even makes sense and whether one should simply use qemu/kvm instead and, and, and... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support
On Tue, 2016-11-01 at 00:04 +0100, Borislav Petkov wrote: > Huh, what does that have to do with disabling the microcode loader? > > Funny... See https://lists.ozlabs.org/pipermail/lguest/2013-May/002001.html . Nobody cared enough to fix it. I cared enough to figure it all out. But I didn't understand much of the possible solutions that where suggested three years ago. I'm certain I still ran into this issue with the microcode loader in the beginning of this year, so that was probably with a v4.4 based guest. Paul Bolle
Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support
On Mon, Oct 31, 2016 at 11:41:19PM +0100, Paul Bolle wrote: > A similar obscure gotcha (I think it is "unhandled trap 13") can be > avoided by launching the guest with the dis_ucode_ldr kernel option. ^ Huh, what does that have to do with disabling the microcode loader? Funny... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: [PATCH 0/8] x86/fpu: Remove CR0.TS support
On Mon, 2016-10-31 at 15:18 -0700, Andy Lutomirski wrote: > I havne't meaningfully tested lguest because I can't get it to work > even without these patches. Have you disabled CONFIG_OLPC in the .config for the guest kernel? Otherwise you will run into lguest: Reinjecting trap 13 for fault at 0x162: Invalid argument A similar obscure gotcha (I think it is "unhandled trap 13") can be avoided by launching the guest with the dis_ucode_ldr kernel option. Hope this helps, Paul Bolle
[PATCH 0/8] x86/fpu: Remove CR0.TS support
We don't do anything useful with CR0.TS anymore, so remove most of our support for it. I havne't meaningfully tested lguest because I can't get it to work even without these patches. Andy Lutomirski (8): fpu/init: Get rid of two redundant clts() calls fpu/bugs: Stop saving and restoring CR0.TS in fpu__init_check_bugs() x86/fpu: Remove irq_ts_save() and irq_ts_restore() x86/kvm: Remove host CR0.TS manipulation lguest: Remove CR0.TS support x86/fpu: #NM without FPU emulation is an error x86/fpu: Remove stts() x86/fpu: Remove clts() arch/x86/include/asm/fpu/api.h| 10 -- arch/x86/include/asm/lguest_hcall.h | 1 - arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 2 -- arch/x86/include/asm/special_insns.h | 13 - arch/x86/kernel/fpu/bugs.c| 7 --- arch/x86/kernel/fpu/core.c| 29 - arch/x86/kernel/fpu/init.c| 18 -- arch/x86/kernel/paravirt.c| 1 - arch/x86/kernel/paravirt_patch_32.c | 2 -- arch/x86/kernel/paravirt_patch_64.c | 2 -- arch/x86/kernel/traps.c | 20 arch/x86/kvm/vmx.c| 12 arch/x86/kvm/x86.c| 5 - arch/x86/lguest/boot.c| 29 +++-- arch/x86/xen/enlighten.c | 13 - drivers/char/hw_random/via-rng.c | 8 ++-- drivers/crypto/padlock-aes.c | 23 ++- drivers/crypto/padlock-sha.c | 18 -- drivers/lguest/hypercalls.c | 4 drivers/lguest/lg.h | 1 - drivers/lguest/x86/core.c | 19 +-- 22 files changed, 32 insertions(+), 210 deletions(-) -- 2.7.4
