Re: [Qemu-devel] [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

[Avi Kivity]

On 02/09/2012 06:32 PM, Jan Kiszka wrote:
> >>
> >> We need to patch the causing instruction, so we have to know where it
> >> starts. Or what do you mean?
> > 
> > Just don't deal with this at all, no one runs on kernels without kernel
> > irqchip.
>
> Not true for upstream, 

It was introduced in 2.6.24?  Is anyone running anything earlier?

I hope that qemu-1.1 will default to kvm irqchip.  In fact we should
start thinking about deprecating apic-less kvm (in the kernel).

> and not a design goal of this approach,
> specifically when considering that it also works with TCG. Would be a
> pity to lose this generality.

It doesn't really speed up tcg, does it?

>
> > 
> >>>
> >>> I'm not sure if the ABI guarantees anything about %rip.
> >>
> >> That's indeed a point. It's likely coupled to the emulator's internals
> >> and when it calls out to user space for MMIO write. How to deal with it?
> > 
> > One way is to verify that it worked this way at least N versions back,
> > and then retro-doc it.  The downside is that it reduces our flexibility
> > in the future, but I think that's a small downside.
>
> It need not reduce our flexibility, we just need to signal to user space
> when our behaviour changes again.

This means that if this code detects that rip is no longer accurate
using this signal, it has to disable itself.  That's not something we
want, I think.

> >>
> >> I'm not sure if Windows has this properly set up for the UP HAL. I
> >> rather think this was a bug in the original implementation. The ROM uses
> >> 0 as CPU index in UP mode unconditionally, so should we in QEMU.
> > 
> > I mean just check kpcr.self.
>
> Yes, clear, but that means that Windows must have initialized FS.base to
> point to the KPCR also in UP mode. Is that really the case? E.g. when
> ACPI is off?! 

No idea.

> I wonder if that explains the reported bug of qemu-kvm
> with -no-acpi and in-kernel irqchip...

acpi-less smp?  it exists but rarely used.  It could explain the
problem, yes.

> >>
> >> I know, and it caused some pain to write it (not only to find out how to
> >> solve it technically). We would need to pass the RAM memory region down
> >> to this freaky device, like we do to the i440fx for PAM purposes. But,
> >> well, that is not straightforward right now. Better ideas welcome.
> > 
> > Could we make it a child<> of i440FX, and have i440FX pass it the
> > MemoryRegion directly?
> > 
> > It means we'll need to redo the glue for new chipsets, but it should be
> > just a few lines.
>
> Hmm... not really nice. It is rather a child of the APIC than of the
> chipset IMHO. Moving it over would also mean establishing logical link
> to the APIC from there. 

Clearly it's involved with the 440fx as well, as it has the magical
ability to turn ROM into RAM.

> It is really an ugly beast...

Oh yes.

-- 
error compiling committee.c: too many arguments to function