> -----Original Message----- > From: kvm-owner@xxxxxxxxxxxxxxx > [mailto:kvm-owner@xxxxxxxxxxxxxxx] On Behalf Of Anthony Liguori > Sent: Tuesday, May 12, 2009 6:18 AM > To: Hollis Blanchard > Cc: Gregory Haskins; Avi Kivity; Chris Wright; Gregory > Haskins; linux-kernel@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx > Subject: Re: PowerPC page faults > > 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 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 don't think this can come true if it is software managed TLB. For guest will never know the content of its TLB without the help of software. > > 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? Yes, but more there is a search in guest TLB to see if it is a guest TLB miss currently. A big overhead, especially for a large TLB without being organized by sth. like rbtree. -- 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
