All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@qumranet.com>
To: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: kvm-ppc-devel
	<kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	kvm-devel
	<kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: [kvm-ppc-devel] RFC: MMIO endianness flag
Date: Thu, 10 Jan 2008 06:56:25 +0000	[thread overview]
Message-ID: <4785C199.9040002@qumranet.com> (raw)
In-Reply-To: <1199920008.5637.48.camel@basalt>

Hollis Blanchard wrote:
> Add an "is_bigendian" flag to the kvm_run.mmio structure.
>
> This is needed for architectures that can make both little- and
> big-endian memory accesses.
>
> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
> ---
>
> PowerPC has different instructions for native and byte-reversed memory
> accesses, and some implementations can also can map individual pages as
> byte-reversed. Right now in the PowerPC KVM implementation the kernel
> detects byte-reversed MMIO from the guest and converts the data as
> appropriate so that userland only ever deals with big-endian data.
>
> That's fine and all, but I started thinking about supporting MMIO
> passthrough, in which userland wouldn't emulate an MMIO at all, but
> rather execute it on the real hardware (via mmap /dev/mem, for example).
>
> In that case, it's actually very important that the endianness of the
> access be preserved, since we need that information to access the real
> hardware.
>
> I don't think this patch has any serious x86 ABI implications, since
> current x86 code just ignores the flag. I guess x86 could continue to
> ignore it in the future, or it could explicitly zero the new flag.
>   

Ignoring the field is better since older kernels won't zero it.

IIRC endianness is a per-page attribute on ppc, no?  Otherwise you'd 
have a global attribute instead of per-access.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel

WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: kvm-ppc-devel
	<kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	kvm-devel
	<kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: RFC: MMIO endianness flag
Date: Thu, 10 Jan 2008 08:56:25 +0200	[thread overview]
Message-ID: <4785C199.9040002@qumranet.com> (raw)
In-Reply-To: <1199920008.5637.48.camel@basalt>

Hollis Blanchard wrote:
> Add an "is_bigendian" flag to the kvm_run.mmio structure.
>
> This is needed for architectures that can make both little- and
> big-endian memory accesses.
>
> Signed-off-by: Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
>
> PowerPC has different instructions for native and byte-reversed memory
> accesses, and some implementations can also can map individual pages as
> byte-reversed. Right now in the PowerPC KVM implementation the kernel
> detects byte-reversed MMIO from the guest and converts the data as
> appropriate so that userland only ever deals with big-endian data.
>
> That's fine and all, but I started thinking about supporting MMIO
> passthrough, in which userland wouldn't emulate an MMIO at all, but
> rather execute it on the real hardware (via mmap /dev/mem, for example).
>
> In that case, it's actually very important that the endianness of the
> access be preserved, since we need that information to access the real
> hardware.
>
> I don't think this patch has any serious x86 ABI implications, since
> current x86 code just ignores the flag. I guess x86 could continue to
> ignore it in the future, or it could explicitly zero the new flag.
>   

Ignoring the field is better since older kernels won't zero it.

IIRC endianness is a per-page attribute on ppc, no?  Otherwise you'd 
have a global attribute instead of per-access.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

  reply	other threads:[~2008-01-10  6:56 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09 23:06 [kvm-ppc-devel] RFC: MMIO endianness flag Hollis Blanchard
2008-01-09 23:06 ` Hollis Blanchard
2008-01-10  6:56 ` Avi Kivity [this message]
2008-01-10  6:56   ` Avi Kivity
     [not found]   ` <4785C199.9040002-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-10 15:23     ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-10 15:23       ` Hollis Blanchard
2008-01-10 15:28       ` [kvm-ppc-devel] " Avi Kivity
2008-01-10 15:28         ` Avi Kivity
     [not found]         ` <4786398C.2090308-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-10 22:57           ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-10 22:57             ` Hollis Blanchard
2008-01-11  2:02             ` [kvm-ppc-devel] [kvm-devel] " Xu, Anthony
2008-01-11  2:02               ` [kvm-ppc-devel] " Xu, Anthony
     [not found]               ` <51CFAB8CB6883745AE7B93B3E084EBE201620FD0-wq7ZOvIWXbOiAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2008-01-11 14:55                 ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-01-11 14:55                   ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-14  5:42                   ` [kvm-ppc-devel] [kvm-devel] " Xu, Anthony
2008-01-14  5:42                     ` [kvm-ppc-devel] " Xu, Anthony
     [not found]                     ` <51CFAB8CB6883745AE7B93B3E084EBE2016214A1-wq7ZOvIWXbOiAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2008-01-14 16:53                       ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-01-14 16:53                         ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-13  9:42             ` [kvm-ppc-devel] [kvm-devel] " Avi Kivity
2008-01-13  9:42               ` [kvm-ppc-devel] " Avi Kivity
     [not found]               ` <4789DD0C.4010600-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-14 16:51                 ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-01-14 16:51                   ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-14 17:30                   ` [kvm-ppc-devel] [kvm-devel] " Avi Kivity
2008-01-14 17:30                     ` [kvm-ppc-devel] " Avi Kivity
     [not found]                     ` <478B9C41.80105-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-14 20:43                       ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-01-14 20:43                         ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-15 14:57                         ` [kvm-ppc-devel] [kvm-devel] " Avi Kivity
2008-01-15 14:57                           ` [kvm-ppc-devel] " Avi Kivity
     [not found]                           ` <478CC9EF.9020907-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-15 16:22                             ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-01-15 16:22                               ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-15  2:43                   ` [kvm-ppc-devel] [kvm-devel] " Xu, Anthony
2008-01-15  2:43                     ` [kvm-ppc-devel] " Xu, Anthony
     [not found]                     ` <51CFAB8CB6883745AE7B93B3E084EBE2016217AB-wq7ZOvIWXbOiAffOGbnezLfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2008-01-15  3:54                       ` [kvm-ppc-devel] [kvm-devel] " Hollis Blanchard
2008-01-15  3:54                         ` [kvm-ppc-devel] " Hollis Blanchard
2008-01-10 15:37       ` Jimi Xenidis
2008-01-10 15:37         ` Jimi Xenidis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4785C199.9040002@qumranet.com \
    --to=avi@qumranet.com \
    --cc=hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=kvm-ppc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.