Am 13.09.2013 um 21:21 schrieb Paul Mackerras <paulus@xxxxxxxxx>: > On Fri, Sep 13, 2013 at 01:36:25PM -0500, Alexander Graf wrote: >> >> On 05.09.2013, at 22:21, Paul Mackerras wrote: >> >>> This adds the ability for userspace to read and write the LPCR >>> (Logical Partitioning Control Register) value relating to a guest >>> via the GET/SET_ONE_REG interface. There is only one LPCR value >>> for the guest, which can be accessed through any vcpu. Userspace >>> can only modify the following fields of the LPCR value: >>> >>> DPFD Default prefetch depth >>> ILE Interrupt little-endian >>> TC Translation control (secondary HPT hash group search disable) >>> >>> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx> >> >> There are 3 things I dislike about this patch :) >> >> 1) A vcpu one_reg should only change the state of the vcpu it's targeting. You want a vm wide thing. > > In hardware there is in fact an LPCR per hardware CPU thread, though > the architecture says that on threaded processors many of the fields > have to be the same on each thread, including the three fields > mentioned here. Ok. Is it mandatory to be identical per core? Or per vm? > >> 2) If anyone gets crazy enough to implement HV emulation in PR KVM this would overlap with the guest's guest LPCR, so we need to name it differently. It's really VM configuration, not a register. Maybe ENABLE_CAP is a better fit? > > If we were doing HV emulation in PR KVM then there would still only be > one LPCR per guest vcpu. If there was a hypervisor running as the PR > guest, it would be its job to context switch the LPCR between its > guests. So I don't see why there would be any need for the top-level > KVM to know about the guest's guest LPCR. > > In that situation we would need a one_reg to get and set the guest's > LPCR, which would be per vcpu, and there would be no restriction on > which bits could be set by the host. Thinking about this a bit more I think you might be correct. > > It sounds to me like the best option would be to keep an LPCR per vcpu > and use the one_reg interface to let the host get and set it. The > actual LPCR applied when the guest runs would use some bits from the > per-vcpu value plus some bits set by the KVM host code (for the host's > protection). How does that sound? Sounds similar to what you have, just that it's on vcpu level now :). I think that would work, yeah. Alex > > Alternatively I could define a new per-VM ioctl. ENABLE_CAP doesn't > really help since it also is per-vcpu, not per-VM. > >> 3) Checkpatch fails: >> >> WARNING: please, no space before tabs >> #59: FILE: arch/powerpc/include/asm/reg.h:295: >> +#define LPCR_TC ^I0x00000200^I/* Translation control */$ > > Oops, will fix. > > Paul. -- 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
