On Sat, Feb 11, 2012 at 14:18, Jan Kiszka <jan.kiszka@xxxxxx> wrote: > On 2012-02-11 15:11, Blue Swirl wrote: >> On Sat, Feb 11, 2012 at 14:00, Jan Kiszka <jan.kiszka@xxxxxx> wrote: >>> On 2012-02-11 14:54, Blue Swirl wrote: >>>> On Sat, Feb 11, 2012 at 12:43, Jan Kiszka <jan.kiszka@xxxxxx> wrote: >>>>> On 2012-02-11 12:49, Andreas Färber wrote: >>>>>> Am 11.02.2012 12:25, schrieb Blue Swirl: >>>>>>> I think using cpu_single_env is an indication of a problem, like poor >>>>>>> code, layering violation or poor API (vmport). What is your use case? >>>>>> >>>>>> I couldn't spot any in this series. Jan, note that any new use of env or >>>>>> cpu_single_env will need to be redone when we convert to QOM CPU. >>>>> >>>>> cpu_single_env should have nothing to do with QOM. >>>>> >>>>> The ABIs of vmport and the KVM VAPI require a reference to the calling >>>>> VCPU, and that's why you find tons of them in patch 5. >>>> >>>> Yes, this seems to be another case of a badly designed ABI. I guess >>>> there is no way to change that anymore, just like vmport? >>> >>> Believe me, I grumbled over it more than once while porting it from >>> qemu-kvm. The point is that some (Windows) VMs out there are running >>> already with this option ROM loaded and working this unfortunate ABI. >> >> Maybe in time those could be deprecated and a ROM using a sane ABI >> introduced instead. After some grace time the old ABI could be finally >> removed. > > At some point. But now we have this interface and no other even thought > out. Given that we want to provide a migration path from qemu-kvm to > upstream rather sooner than later, I think there is no way around this > model for a certain, not too short period. Yes, that is inevitable. >> >>>> >>>> Some of the cpu_single_env accesses in patch 5 could be avoided when >>>> APIC is moved closer to CPU. VAPIC should be also close to APIC so it >>>> should be able to access the CPU directly. In some other cases the >>>> current state could be passed around instead once it is known. >>> >>> Some callbacks are I/O-port originated, ie. not associated with the >>> per-CPU MMIO area or some MSR. So we would have to pass down the causing >>> CPU to every I/O handler - not sure if that is desired... >> >> I meant things like vapic_enable_tpr_reporting(), current CPUState >> could be passed via vapic_prepare() easily. > > Oh, there is in fact dead code in vapic_enable_tpr_reporting. It just > iterates over all VCPUs, no need to know the current one. Ok. > Jan > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
