Re: [kvm-ppc-devel] RFC: MMIO endianness flag

[Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

On Tue, 2008-01-15 at 16:57 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> >> btw, isn't passthrough better handled through the tlb?  i.e. actually 
> >> let the guest access the specially-configured memory?  You can have qemu 
> >> mmap /dev/mem and install it as a memslot, and things should work, no?  
> >> (well, you might need to set some cachablility flag or other).
> >>     
> >
> > Hmm, yes you're right. Of course, qemu offers greater flexibility than
> > MMUs (which are limited to page-sized granularity, for example), so it
> > might still be useful to have qemu intercede.
> >
> >   
> 
> With the endian-aware instructions that doesn't matter, since you set 
> the endianness on a per-instruction granularity.  And with guest tlb 
> controlled endianness, surely you get page granularity as well?
> 
> 
> > Since we're defining a stable ABI, I'd rather have the information
> > present than miss it in the future...
> 
> So now the question is, do we see the need for qemu to intercept writes 
> to pass-through devices?  IMO the answer is no.  If it doesn't 
> understand anything about the device, it would be better off doing a 
> real pass through.  If it does understand the device, it should know 
> which endianness it likes.

OK, I'm willing to go along with this, and hope that we don't run into
another use case for an endianness flag in the future.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/