On 2012-02-09 17:47, Avi Kivity wrote: > 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. I don't expect the MSI thing cleaned up and upstreamed by then. So the question is if we want to disable MSI by default - I guess not... > In fact we should > start thinking about deprecating apic-less kvm (in the kernel). Not a good idea as it allows to stress user space code in KVM mode that is not going to be deprecated (as it is used without KVM as well). > >> 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? Nope, but it removes yet another blocking point for TCG<->KVM migration. > >> >>> >>>>> >>>>> 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. ...or it could check in the other direction, i.e. forward. I think there are only two reasonable options for the emulator. We could encode them in a KVM_CAP return code. > >>>> >>>> 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. Testing right now... > >>>> >>>> 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. I think all our ROM is in shadow RAM, only protected by the PAM settings. We could also reconfigure PAM in the guest, but the granularity does not match, and it would not be compatible with older VAPIC ROMs. We could establish a side channel to the chipset and linking the kvmvapic to it at board level. That link could point to any chipset supporting the interface. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
