On Monday 11 May 2009 17:17:53 Anthony Liguori wrote: > Hollis Blanchard wrote: > > On Mon, 2009-05-11 at 12:54 -0500, Anthony Liguori wrote: > > > >> For future ppcemb's, do you know if there is an equivalent of a PF exit > >> type? Does the hardware squirrel away the faulting address somewhere > >> and set PC to the start of the instruction? If so, no guest memory load > >> should be required. > >> > > > > Ahhh... you're saying that the address itself (or offset within a page) > > is the hypercall token, totally separate from IO emulation, and so we > > could ignore the access size. > > No, I'm not being nearly that clever. I started thinking you weren't, but then I realized you must be working several levels above me and just forgot to explain... :) > I was suggesting that hardware virtualization support in future PPC > systems might contain a mechanism to intercept a guest-mode TLB miss. > If it did, it would be useful if that guest-mode TLB miss "exit" > contained extra information somewhere that included the PC of the > faulting instruction, the address response for the fault, and enough > information to handle the fault without instruction decoding. > > I assume all MMIO comes from the same set of instructions in PPC? > Something like ld/st instructions? Presumably all you need to know from > instruction decoding is the destination register and whether it was a > read or write? In addition to register source/target, we also need to know the access size of the memory reference. That information isn't stuffed into registers for us by hardware, and it's not in published specifications for future hardware. Now, if you wanted to define a hypercall as a byte access within a particular 4K page, where the register source/target is ignored, that could be interesting, but I don't know if that's relevant to this "hypercall vs MMIO" discussion. -- Hollis Blanchard IBM Linux Technology Center -- 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