On 4 December 2012 13:37, Dong Aisheng <b29396@xxxxxxxxxxxxx> wrote: > On Tue, Dec 04, 2012 at 12:45:12PM +0000, Peter Maydell wrote: >> On 4 December 2012 12:27, Dong Aisheng <b29396@xxxxxxxxxxxxx> wrote: >> > On Mon, Dec 03, 2012 at 01:22:07PM +0000, Peter Maydell wrote: >> >> What we're really providing the guest here is a hardware-accelerated >> >> software emulation of a no-virtualization GICv2. So it's better for >> >> the state we expose to userspace to be the state of that emulated >> >> hardware, and not to expose details of exactly what that hardware >> >> acceleration is. >> > >> > It looks like a good idea. >> > Then in which format? User space qemu and kernel space vgic are using >> > different data format to describe gic state. >> > We definitely need a standard one to use with good compatibility. >> > One simple way may be just registers value of no-virtualization GICv2. >> >> "Values of registers" and "state of a device" are not identical >> (though the internal state is often made visible via registers). >> We care about the latter, not the former. > I agree your point, the problem is how to define a standard "state of > gic device"? Yes, indeed; that is exactly the major design question which your patch needs to solve. > The gic registers format is the exist one and both kernel or user space > state code changes do not affect each other. Just to be clear here, "the gic registers format" is not a sufficient definition of the GIC internal state. To take a simple example, the distributor registers include a set of "set-enable" registers GICD_ISENABLERn and a set of "clear enable" registers GICD_ICENABLERn. These are two views (and ways to alter) a single set of underlying "enable" bits. What we want from userspace is a way to read and write the enable bits. We do not want an interface that has the "write 1 to set/write 1 to clear" semantics of the hardware registers. Obviously often registers are a simple read/write view of underlying state, but this isn't always true. > One concern is that i'm still not sure if there will be no issue > if not saving virtual interface control registers. > It may need some time to research. > > Maybe we convert it into standard state and restore it back then. > But some bits of them may not be exported. Yes, confirming that the state as exposed via the virtual interface control registers can be correctly converted into our canonical state representation is a good cross-check that we have got it right. We definitely mustn't lose information, or migration won't work right in some edge case. -- PMM -- 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
