Re: [Xen-devel] [PATCH v2 2/2] x86/HVM: fix ID handling of x2APIC emulation

[Tim Deegan <tim@xxxxxxx>]

At 14:22 +0100 on 18 Sep (1411046578), Jan Beulich wrote:
> > It would, I think, be reasonable to abandon the fix altogether and
> > just let upgraded VMs continue with their bogus state -- after all it
> > can't be that much of a problem for them or they'd have failed on the
> > old box.
> 
> No, we can't drop it, because it doesn't fix only LDR. It also changes
> the ID representation (since in particular the GET_xAPIC_ID() use
> gets dropped from hvm_x2apic_msr_read()'s APIC_ID case), and this
> one must be transparent to the guest.

Ah, right.

> >> Nor do I think we should (implicitly) disallow restoring the same
> >> state more than once before resuming the guest (or vCPU).
> > 
> > True, but that's true whether we do the fix at unpause or beforehand.
> 
> No, it's not: If the first load resulted in x2APIC mode and the
> second one not, we'd have done an adjustment already which we
> would better not have done.

What I mean is: we also ought to handle multiple restores even with
unpauses between them (like COLO, though IIRC that won't actually
unpause), or else explicitly disallow them.

> But I think I can see another alternative: Latch the most recently
> loaded or live ID and LDR values into struct vlapic and restore
> them into register state when hidden state got updated, applying
> the fix immediately afterwards. Any write to those two registers
> (or perhaps just any live register access) would then clear the
> "loaded" state.

Yes, I think that makes sense.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel