Re: [PATCH 2/2] add sysenter/syscall emulation for 32bit compat mode

[Andre Przywara <andre.przywara@amd.com>]

Hi Avi,

>> --- a/arch/x86/kvm/x86_emulate.c
>> +++ b/arch/x86/kvm/x86_emulate.c
>> @@ -32,6 +32,8 @@
>>  #include <linux/module.h>
>>  #include <asm/kvm_x86_emulate.h>
>>  
>> +#include "mmu.h"
>> +
>>   
> 
> I think this is unneeded?
Seems so. Probably a left-over from debugging.
> 
>> @@ -1985,10 +1992,114 @@ twobyte_insn:
>>              goto cannot_emulate;
>>          }
>>          break;
>> +    case 0x05: { /* syscall */
>> +        unsigned long cr0 = ctxt->vcpu->arch.cr0;
>> +        struct kvm_segment cs, ss;
>> +
>> +        memset(&cs, 0, sizeof(struct kvm_segment));
>> +        memset(&ss, 0, sizeof(struct kvm_segment));
>> +
>> +        /* inject #UD if
>> +         * 1. we are in real mode
>> +         * 2. protected mode is not enabled
>> +         * 3. LOCK prefix is used
>> +         */
>> +        if ((ctxt->mode == X86EMUL_MODE_REAL)
>> +            || (!(cr0 & X86_CR0_PE))
>> +            || (c->lock_prefix)) {
>> +            /* we don't need to inject #UD here, because
>> +             * when emulate_instruction() returns something else
>> +             * than EMULATE_DONE, then svm.c:ud_interception()
>> +             * will do that for us.
>> +             */
>> +            goto cannot_emulate;
>>   
> 
> I prefer explicit injection, relying on the caller is tricky and may 
> change.
I don't agree. If this function cannot emulate an instruction, it 
returns -1 and lets the upper levels handle this. If we cannot rely on 
this, what else can we rely on? I could remove the comment in case this 
is confusing. The same functionality (return -1 to inject UD into the 
guest) is used in other places in this same file.

> 
>> +    case 0x07:        /* sysret */
>>   
> 
> Since we don't emulate sysret, it should be dropped here.
OK, will do.
> 
>> +            cs.limit = 0xffffffff;
>> +            ss.base = 0;
>> +            ss.limit = 0xffffffff;
>>   
> 
> Once is enough.
You are right about the ss.base assignment. But the limit goes from five 
f's to eight f's. On a first glance this should not matter (as the 
granularity bit is set), but exactly here are differences between VMX 
and SVM, so I'd like to leave it this way.
> 
> Please move the code out of the switch and into separate functions.

Ok, will do.

Thanks for the review!
Renewed patch will follow.

Regards,
Andre.

-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712