* [PATCH kvm-unit-tests] x86: fix last commit
@ 2015-07-30 13:38 Paolo Bonzini
2015-08-01 15:41 ` Shih-Wei Li
0 siblings, 1 reply; 7+ messages in thread
From: Paolo Bonzini @ 2015-07-30 13:38 UTC (permalink / raw)
To: kvm; +Cc: shihwei, bsd
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH kvm-unit-tests] x86: fix last commit
2015-07-30 13:38 [PATCH kvm-unit-tests] x86: fix last commit Paolo Bonzini
@ 2015-08-01 15:41 ` Shih-Wei Li
2015-08-01 19:05 ` Bandan Das
0 siblings, 1 reply; 7+ messages in thread
From: Shih-Wei Li @ 2015-08-01 15:41 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: kvm, bsd
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH kvm-unit-tests] x86: fix last commit
2015-08-01 15:41 ` Shih-Wei Li
@ 2015-08-01 19:05 ` Bandan Das
2015-08-01 20:49 ` Paolo Bonzini
0 siblings, 1 reply; 7+ messages in thread
From: Bandan Das @ 2015-08-01 19:05 UTC (permalink / raw)
To: Shih-Wei Li; +Cc: Paolo Bonzini, kvm
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
>>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH kvm-unit-tests] x86: fix last commit
2015-08-01 19:05 ` Bandan Das
@ 2015-08-01 20:49 ` Paolo Bonzini
2015-08-01 21:20 ` Bandan Das
0 siblings, 1 reply; 7+ messages in thread
From: Paolo Bonzini @ 2015-08-01 20:49 UTC (permalink / raw)
To: Bandan Das, Shih-Wei Li; +Cc: kvm
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH kvm-unit-tests] x86: fix last commit
2015-08-01 20:49 ` Paolo Bonzini
@ 2015-08-01 21:20 ` Bandan Das
2015-08-01 21:59 ` Shih-Wei Li
2015-08-02 7:47 ` Paolo Bonzini
0 siblings, 2 replies; 7+ messages in thread
From: Bandan Das @ 2015-08-01 21:20 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Shih-Wei Li, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH kvm-unit-tests] x86: fix last commit
2015-08-01 21:20 ` Bandan Das
@ 2015-08-01 21:59 ` Shih-Wei Li
2015-08-02 7:47 ` Paolo Bonzini
1 sibling, 0 replies; 7+ messages in thread
From: Shih-Wei Li @ 2015-08-01 21:59 UTC (permalink / raw)
To: Bandan Das; +Cc: Paolo Bonzini, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH kvm-unit-tests] x86: fix last commit
2015-08-01 21:20 ` Bandan Das
2015-08-01 21:59 ` Shih-Wei Li
@ 2015-08-02 7:47 ` Paolo Bonzini
1 sibling, 0 replies; 7+ messages in thread
From: Paolo Bonzini @ 2015-08-02 7:47 UTC (permalink / raw)
To: Bandan Das; +Cc: Shih-Wei Li, kvm
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-08-02 7:47 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-30 13:38 [PATCH kvm-unit-tests] x86: fix last commit Paolo Bonzini
2015-08-01 15:41 ` Shih-Wei Li
2015-08-01 19:05 ` Bandan Das
2015-08-01 20:49 ` Paolo Bonzini
2015-08-01 21:20 ` Bandan Das
2015-08-01 21:59 ` Shih-Wei Li
2015-08-02 7:47 ` Paolo Bonzini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.