On 07.02.2011, at 20:56, Yoder Stuart-B08248 wrote: > > >> -----Original Message----- >> From: Wood Scott-B07421 >> Sent: Monday, February 07, 2011 12:52 PM >> To: Alexander Graf >> Cc: Yoder Stuart-B08248; Wood Scott-B07421; kvm-ppc@xxxxxxxxxxxxxxx; >> kvm@xxxxxxxxxxxxxxx; qemu-devel@xxxxxxxxxx >> Subject: Re: RFC: New API for PPC for vcpu mmu access >> >> On Mon, 7 Feb 2011 17:49:51 +0100 >> Alexander Graf <agraf@xxxxxxx> wrote: >> >>> >>> On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote: >>> >>>> Suggested change to this would be to have Qemu set tlb_type as >>>> an _input_ argument. If KVM supports it, that type gets used, >>>> else an error is returned. This would allow Qemu to tell >>>> the kernel what type of MMU it is prepared to support. Without >>>> this Qemu would just have to error out if the type returned is >>>> unknown. >>> >>> Yes, we could use the same struct for get and set. On set, it could >> transfer the mmu type, on get it could tell userspace the mmu type. >> >> What happens if a get is done before the first set, and there are multiple >> MMU type options for this hardware, with differing entry sizes? >> >> Qemu would have to know beforehand how large to make the buffer. >> >> We could say that going forward, it's expected that qemu will do a TLB set >> (either a full one, or a lightweight alternative) after creating a vcpu. >> For compatibility, if this doesn't happen before the vcpu is run, the TLB >> is created and initialized as it is today, but no new Qemu-visible features >> will be enabled that way. > > Since I think the normal thing Qemu would want to do is determine > the type/size before allocating space for the TLB, we could just > pass in NULL for tlb_data on the first set. If tlb_data is > NULL we just set the MMU type and return the size (and type). It could also pass in some sort of max size - as long as nobody touches that memory it's almost for free. Alex -- 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
