Re: [Qemu-devel] [PATCH] kvm: fix Win2k boot without KVM

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

On 2012-11-03 20:03, Jan Kiszka wrote:
> On 2012-11-03 19:56, Blue Swirl wrote:
>> On Sat, Nov 3, 2012 at 6:51 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>> On 2012-11-03 19:49, Blue Swirl wrote:
>>>> Ignore accesses to VAPIC when kvmvapic is not enabled.
>>>>
>>>> Cc: Jan Kiszka <jan.kiszka@web.de>
>>>> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
>>>> ---
>>>>  hw/kvmvapic.c |    7 ++++---
>>>>  1 files changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/hw/kvmvapic.c b/hw/kvmvapic.c
>>>> index dc111ee..a97d532 100644
>>>> --- a/hw/kvmvapic.c
>>>> +++ b/hw/kvmvapic.c
>>>> @@ -612,6 +612,9 @@ static void vapic_write(void *opaque, hwaddr addr, uint64_t data,
>>>>      hwaddr rom_paddr;
>>>>      VAPICROMState *s = opaque;
>>>>
>>>> +    if (!kvm_irqchip_in_kernel()) {
>>>> +        return;
>>>> +    }
>>>>      cpu_synchronize_state(env);
>>>>
>>>>      /*
>>>> @@ -665,9 +668,7 @@ static void vapic_write(void *opaque, hwaddr addr, uint64_t data,
>>>>          break;
>>>>      default:
>>>>      case 4:
>>>> -        if (!kvm_irqchip_in_kernel()) {
>>>> -            apic_poll_irq(env->apic_state);
>>>> -        }
>>>> +        apic_poll_irq(env->apic_state);
>>>>          break;
>>>>      }
>>>>  }
>>>>
>>>
>>> NACK, I'm already debugging the true reason (related to code patching).
>>
>> This is a minimal fix that lets Win2k boot, now it does not work at
>> all. I think it should be applied for 1.3, it can be reverted when
>> (if) you find a better fix. There's no hurry though.
> 
> If you want to disable it, flip apic.vapic for !kvm_enabled. Your patch
> affects user space APIC with KVM as well, though that is perfectly fine.
> 
> But first of all give this some days as I just started.

...even more as this regression may not be related to the introduction
of the kvmvapic: My original test case for the kvmvapic under TCG,
WinXP, is now also broken, causing a segfault too.

What I'm seeing is that tb_invalidate_phys_page_range in
patch_instruction no longer seems to detect that the currently executed
tb was just changed. Any ideas what may cause this are welcome.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]