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
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 cachablilit
On Tue, 2008-01-15 at 10:43 +0800, Xu, Anthony wrote:
> > Here is the concrete example:
> > * guest writes to MMIO
> > * KVM passes MMIO information (physical address, number of
> > bytes, value) to qemu
> The value is saved in memory, is it bigendian or
> littleen
> Here is the concrete example:
> * guest writes to MMIO
> * KVM passes MMIO information (physical address, number of
> bytes, value) to qemu
The value is saved in memory, is it bigendian or
littleendian?
> * Qemu knows from the address that this access is
On Mon, 2008-01-14 at 19:30 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> > On Sun, 2008-01-13 at 11:42 +0200, Avi Kivity wrote:
> >
> >
> >> Do we really need to propagate endianness all the way to the user?
> >> Perhaps libkvm could call the regular mmio functions and do the
> >> tra
Hollis Blanchard wrote:
> On Sun, 2008-01-13 at 11:42 +0200, Avi Kivity wrote:
>
>
>> Do we really need to propagate endianness all the way to the user?
>> Perhaps libkvm could call the regular mmio functions and do the
>> transformation itself.
>>
>> Or maybe even the kernel can do this by i
I hope I've explained in the other mail I just sent why Qemu assuming
little-endian for everything is not OK.
One other important clarification: kvm_run->mmio.is_bigendian is about
*one* *particular* *MMIO* *access*. It has only coincidental
relationship to the "endianness mode" of the guest.
--
On Sun, 2008-01-13 at 11:42 +0200, Avi Kivity wrote:
> Do we really need to propagate endianness all the way to the user?
> Perhaps libkvm could call the regular mmio functions and do the
> transformation itself.
>
> Or maybe even the kernel can do this by itself?
The kernel *already* does th
> kvm_run->mmio.is_bigendian = vcpu->arch.some_register &
>From your example code, I can know is_bigendian indicate whether guest
is in bigendian mode when accessing MMIO.
Qemu is responsible for handling MMIO emulation, Qemus always assume it
is running on littleendian mode.
So if guest
Hollis Blanchard wrote:
> On Thu, 2008-01-10 at 17:28 +0200, Avi Kivity wrote:
>
>> I'll apply that patch (with a #ifdef CONFIG_PPC so other archs don't
>> use it by mistake).
>>
>
> I don't think that's the right ifdef. For example, I believe IA64 can
> run in BE mode and so will have the
We're just talking about a flag in the kvm_run.mmio structure, so it
does not represent the state of any software, guest or host, other than
that single MMIO access.
This flag is only used for communication between host kernel and host
userland, so the host kernel is always responsible for setting
Hi all,
That's a good start to consider BE.
Yes, IA64 support BE and LE.
I have below comments.
What does is_bigendian mean?
Host is runing with BE or guest is running with BE.
Who will set is_bigendian?
For supporing BE,
We need to consider host BE and guest BE.
For IA64, most OS is running w
On Thu, 2008-01-10 at 17:28 +0200, Avi Kivity wrote:
> I'll apply that patch (with a #ifdef CONFIG_PPC so other archs don't
> use it by mistake).
I don't think that's the right ifdef. For example, I believe IA64 can
run in BE mode and so will have the same issue, and there are certainly
other arch
On Jan 10, 2008, at 10:23 AM, Hollis Blanchard wrote:
> On Thu, 2008-01-10 at 08:56 +0200, Avi Kivity wrote:
>>
>> IIRC endianness is a per-page attribute on ppc, no? Otherwise you'd
>> have a global attribute instead of per-access.
>
> The MMU in some PowerPC can have per-page endianness, but n
14 matches
Mail list logo
