[PATCH kvm-unit-tests] x86: fix last commit

[PATCH kvm-unit-tests] x86: fix last commit

[Paolo Bonzini]

Keeping the selector that was loaded from the 32-bit GDT is okay, because
only code segment descriptors differ between 32- and 64-bit mode.  In
fact the same is true for %ss as well, so let's just remove the whole
segment loading from load_tss.

Thanks to Bandan Das for debugging.

Reported-by: Shih-Wei Li <shihwei@cs.columbia.edu>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 x86/cstart64.S | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/x86/cstart64.S b/x86/cstart64.S
index 8d5ee2d..e947888 100644
--- a/x86/cstart64.S
+++ b/x86/cstart64.S
@@ -213,12 +213,6 @@ idt_descr:
 
 load_tss:
 	lidtq idt_descr
-	mov $0x10, %eax
-	mov %ax, %ds
-	mov %ax, %es
-	mov %ax, %fs
-	mov %ax, %gs
-	mov %ax, %ss
 	mov $(APIC_DEFAULT_PHYS_BASE + APIC_ID), %eax
 	mov (%rax), %eax
 	shr $24, %eax
-- 
1.8.3.1

Re: [PATCH kvm-unit-tests] x86: fix last commit

[Shih-Wei Li]

Hi Paolo,

I've tried to apply the patch, and found that it passed most of the
problematic tests I mentioned earlier (IPI related, kvmclock_test).
However, it stopped still at "s3" and couldn't finish it. Do you know
what might go wrong?

Thanks,
Shih-Wei

On Thu, Jul 30, 2015 at 9:38 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Keeping the selector that was loaded from the 32-bit GDT is okay, because
> only code segment descriptors differ between 32- and 64-bit mode.  In
> fact the same is true for %ss as well, so let's just remove the whole
> segment loading from load_tss.
>
> Thanks to Bandan Das for debugging.
>
> Reported-by: Shih-Wei Li <shihwei@cs.columbia.edu>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  x86/cstart64.S | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/x86/cstart64.S b/x86/cstart64.S
> index 8d5ee2d..e947888 100644
> --- a/x86/cstart64.S
> +++ b/x86/cstart64.S
> @@ -213,12 +213,6 @@ idt_descr:
>
>  load_tss:
>         lidtq idt_descr
> -       mov $0x10, %eax
> -       mov %ax, %ds
> -       mov %ax, %es
> -       mov %ax, %fs
> -       mov %ax, %gs
> -       mov %ax, %ss
>         mov $(APIC_DEFAULT_PHYS_BASE + APIC_ID), %eax
>         mov (%rax), %eax
>         shr $24, %eax
> --
> 1.8.3.1
>

Re: [PATCH kvm-unit-tests] x86: fix last commit

[Bandan Das]

Shih-Wei Li <shihwei@cs.columbia.edu> writes:

> Hi Paolo,
>
> I've tried to apply the patch, and found that it passed most of the
> problematic tests I mentioned earlier (IPI related, kvmclock_test).
> However, it stopped still at "s3" and couldn't finish it. Do you know
> what might go wrong?

Nothing is wrong, that's the way the test is. You need to resume from
qemu for it to proceed and it should quit with 1 for error or 0 for
success.

> Thanks,
> Shih-Wei
>
> On Thu, Jul 30, 2015 at 9:38 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Keeping the selector that was loaded from the 32-bit GDT is okay, because
>> only code segment descriptors differ between 32- and 64-bit mode.  In
>> fact the same is true for %ss as well, so let's just remove the whole
>> segment loading from load_tss.
>>
>> Thanks to Bandan Das for debugging.
>>
>> Reported-by: Shih-Wei Li <shihwei@cs.columbia.edu>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>  x86/cstart64.S | 6 ------
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/x86/cstart64.S b/x86/cstart64.S
>> index 8d5ee2d..e947888 100644
>> --- a/x86/cstart64.S
>> +++ b/x86/cstart64.S
>> @@ -213,12 +213,6 @@ idt_descr:
>>
>>  load_tss:
>>         lidtq idt_descr
>> -       mov $0x10, %eax
>> -       mov %ax, %ds
>> -       mov %ax, %es
>> -       mov %ax, %fs
>> -       mov %ax, %gs
>> -       mov %ax, %ss
>>         mov $(APIC_DEFAULT_PHYS_BASE + APIC_ID), %eax
>>         mov (%rax), %eax
>>         shr $24, %eax
>> --
>> 1.8.3.1
>>

Re: [PATCH kvm-unit-tests] x86: fix last commit

[Paolo Bonzini]

On 01/08/2015 21:05, Bandan Das wrote:
> Shih-Wei Li <shihwei@cs.columbia.edu> writes:
> 
>> Hi Paolo,
>>
>> I've tried to apply the patch, and found that it passed most of the
>> problematic tests I mentioned earlier (IPI related, kvmclock_test).
>> However, it stopped still at "s3" and couldn't finish it. Do you know
>> what might go wrong?
> 
> Nothing is wrong, that's the way the test is. You need to resume from
> qemu for it to proceed and it should quit with 1 for error or 0 for
> success.

Actually it should be using the RTC alarm to wake itself up.  But the
firmware changed recently and the ACPI PMBASE moved from 0xb000 to
0x600.  Try this (untested):

diff --git a/x86/s3.c b/x86/s3.c
index d568aa7..d6cfef3 100644
--- a/x86/s3.c
+++ b/x86/s3.c
@@ -177,7 +177,7 @@ int main(int argc, char **argv)
 	rtc_out(RTC_REG_B, rtc_in(RTC_REG_B) | REG_B_AIE);
 
 	*(volatile int*)0 = 0;
-	asm volatile("outw %0, %1" :: "a"((short)0x2400), "d"((short)0xb004):"memory");
+	asm volatile("outw %0, %1" :: "a"((short)0x2400), "d"((short)0x604):"memory");
 	while(1)
 		*(volatile int*)0 = 1;
 

It's on my todo list to fix a very similar issue in vmexit.flat.

Paolo

Re: [PATCH kvm-unit-tests] x86: fix last commit

[Bandan Das]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 01/08/2015 21:05, Bandan Das wrote:
>> Shih-Wei Li <shihwei@cs.columbia.edu> writes:
>> 
>>> Hi Paolo,
>>>
>>> I've tried to apply the patch, and found that it passed most of the
>>> problematic tests I mentioned earlier (IPI related, kvmclock_test).
>>> However, it stopped still at "s3" and couldn't finish it. Do you know
>>> what might go wrong?
>> 
>> Nothing is wrong, that's the way the test is. You need to resume from
>> qemu for it to proceed and it should quit with 1 for error or 0 for
>> success.
>
> Actually it should be using the RTC alarm to wake itself up.  But the
> firmware changed recently and the ACPI PMBASE moved from 0xb000 to
> 0x600.  Try this (untested):

Ah thanks! your patch works for me. Is this one of the static entries in
the ACPI tables ? I am wondering if we can read this value so it works for
everybody.

> diff --git a/x86/s3.c b/x86/s3.c
> index d568aa7..d6cfef3 100644
> --- a/x86/s3.c
> +++ b/x86/s3.c
> @@ -177,7 +177,7 @@ int main(int argc, char **argv)
>  	rtc_out(RTC_REG_B, rtc_in(RTC_REG_B) | REG_B_AIE);
>  
>  	*(volatile int*)0 = 0;
> -	asm volatile("outw %0, %1" :: "a"((short)0x2400), "d"((short)0xb004):"memory");
> +	asm volatile("outw %0, %1" :: "a"((short)0x2400), "d"((short)0x604):"memory");
>  	while(1)
>  		*(volatile int*)0 = 1;
>  
>
> It's on my todo list to fix a very similar issue in vmexit.flat.
>
> Paolo

Re: [PATCH kvm-unit-tests] x86: fix last commit

[Shih-Wei Li]

Thanks, Paolo! It works for me too.

On Sat, Aug 1, 2015 at 5:20 PM, Bandan Das <bsd@redhat.com> wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
>> On 01/08/2015 21:05, Bandan Das wrote:
>>> Shih-Wei Li <shihwei@cs.columbia.edu> writes:
>>>
>>>> Hi Paolo,
>>>>
>>>> I've tried to apply the patch, and found that it passed most of the
>>>> problematic tests I mentioned earlier (IPI related, kvmclock_test).
>>>> However, it stopped still at "s3" and couldn't finish it. Do you know
>>>> what might go wrong?
>>>
>>> Nothing is wrong, that's the way the test is. You need to resume from
>>> qemu for it to proceed and it should quit with 1 for error or 0 for
>>> success.
>>
>> Actually it should be using the RTC alarm to wake itself up.  But the
>> firmware changed recently and the ACPI PMBASE moved from 0xb000 to
>> 0x600.  Try this (untested):
>
> Ah thanks! your patch works for me. Is this one of the static entries in
> the ACPI tables ? I am wondering if we can read this value so it works for
> everybody.
>
>> diff --git a/x86/s3.c b/x86/s3.c
>> index d568aa7..d6cfef3 100644
>> --- a/x86/s3.c
>> +++ b/x86/s3.c
>> @@ -177,7 +177,7 @@ int main(int argc, char **argv)
>>       rtc_out(RTC_REG_B, rtc_in(RTC_REG_B) | REG_B_AIE);
>>
>>       *(volatile int*)0 = 0;
>> -     asm volatile("outw %0, %1" :: "a"((short)0x2400), "d"((short)0xb004):"memory");
>> +     asm volatile("outw %0, %1" :: "a"((short)0x2400), "d"((short)0x604):"memory");
>>       while(1)
>>               *(volatile int*)0 = 1;
>>
>>
>> It's on my todo list to fix a very similar issue in vmexit.flat.
>>
>> Paolo

Re: [PATCH kvm-unit-tests] x86: fix last commit

[Paolo Bonzini]

On 01/08/2015 23:20, Bandan Das wrote:
>> > Actually it should be using the RTC alarm to wake itself up.  But the
>> > firmware changed recently and the ACPI PMBASE moved from 0xb000 to
>> > 0x600.  Try this (untested):
> Ah thanks! your patch works for me. Is this one of the static entries in
> the ACPI tables ? I am wondering if we can read this value so it works for
> everybody.
> 

Yes, it's PM1a_STS from the PM1a_EVT block; the pointer is in the FADT.

x86/s3.c already has code to look for the FADT, so a fix should be easy.
 On top of that we should move the ACPI tables to a header and the
parsing code to lib/x86, so that the vmexit test can use it to find the
PM_TMR address.

Paolo