On 15.09.2011, at 20:26, Scott Wood wrote: > On 09/05/2011 05:28 PM, Alexander Graf wrote: >>> + /* >>> + * SPRG4-7 are user-readable, so we can't keep these >>> + * consistent between the magic page and the real >>> + * registers. We provide space in case the guest >>> + * can deal with this. >>> + * >>> + * This also applies to SPRG3 on some chips. >>> + */ >>> + __u64 sprg4; >>> + __u64 sprg5; >>> + __u64 sprg6; >>> + __u64 sprg7; >> >> Hrm. You're touching sprg4-7 but don't remove the fields from vcpu->arch. That sounds wrong. Also, the entry/exit code needs to use these now instead of the vcpu struct fields to restore the correct values. > > The original idea, as the comment states, was just to provide an area > that the guest could use for this, as we can't keep it fully synced with > the hardware registers since the hw regs don't trap on read, and the > paravirt doesn't trap on write. Right, but the guest kernel can easily patch its own use and then still wants user space to see them for what they are. Syncing them manually from the kernel side is useless - we could just as well not PV them in the first place. > However, I think it could work reasonably well to use this as the > backing store instead of vcpu->arch.sprg4-7. The guest would still see > inconsistency if it writes to paravirt and then reads from the hw reg > without an intervening exit, so that restriction on use still applies, > but qemu would see the right thing in sregs, and we wouldn't have the > duplication. Yes, also guest user space would still be fine when guest kernel space writes to the PV reg. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
