Messages in this thread | | | Date | Tue, 27 Feb 2007 10:17:19 -0600 | From | Anthony Liguori <> | Subject | Re: [RFC] Use para_fill instead of vmi_get_function for APIC ops |
| |
Zachary Amsden wrote: > Anthony Liguori wrote: >> Hi Zach, >> >> It seems to me that the APIC paravirt_ops should be filled by >> para_fill() instead of vmi_get_function(). vmi_get_function() >> returns a nop when the relocation type is NONE. para_fill() leaves >> the native code in place. >> >> The native version of the apic write ops is more or less *(APIC_BASE >> + reg) = value. APIC_BASE is unknown to the ROM so it's impossible >> to simulate this in the ROM. >> >> This means that a ROM has no choice but to do APIC emulation (or jump >> through seriously hairy loops to get the APIC mapped in it's address >> space). Was this the intention? > > No, but certainly the effect. Actually, it is very easy to get the > APIC mapped in the ROM address space without jumping through seriously > hairy loops - we do it today in our hypervisor.
I neglected to mention that I didn't want to use a memory hole. One could allocate a small one to map the APIC but that seems to defeat the purpose of having a native ROM.
Regards,
Anthony Liguori
>> >> N.B. attached patch is just to illustrate the point. Has not even >> been compile tested. > > > Patch looks good, thanks. But the whole para_fill / vmi_get_function > stuff could probably be done even cleaner. It was just a helper at > first to work around the awkward syntax, and it is still a bit ugly, > but I haven't come up with a better solution yet, mostly because with > the new inlining work Jeremy is doing, we might want to start doing > selective inlining, in which case I'll have to go back over the code > anyway to clean everything to get the logic right in all cases. > > I assume this patch is signed-off-by you? If so, I'll add it to my > patch queue. > > Zach >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |