From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [kvm-ppc-devel] booting from virtio-blk Date: Wed, 02 Apr 2008 07:36:39 +1100 Message-ID: <1207082199.10388.222.camel@pasglop> References: <1207051275240-git-send-email-ehrhardt@linux.vnet.ibm.com> <47F225D2.9020409@linux.vnet.ibm.com> <1207060430.6214.12.camel@basalt> <47F24ABA.3020404@us.ibm.com> <1207066432.6214.29.camel@basalt> <47F26C4D.1090406@us.ibm.com> Reply-To: benh@kernel.crashing.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-ppc-devel@lists.sourceforge.net, kvm-devel , Rusty Russell , Hollis Blanchard To: Anthony Liguori Return-path: In-Reply-To: <47F26C4D.1090406@us.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org On Tue, 2008-04-01 at 12:09 -0500, Anthony Liguori wrote: > It's the unfortunate side-effect of using PCI config space without > passing it's semantics through to the virtio devices. Right now, you do > a config_get which is basically a memcpy. If we didn't do accesses with > ioread8(), you could potentially have a caller than did a config_get() > of size 4 that didn't intend on having endian conversion applied. > > The other option would have been to provide config_get() and > config_get8/16/32/64() the later performing endian conversion. Config space should be 8/16/32. Is that ever bridged to real PCI config space anyway ? Or only virtio ? And it should be endian swapped at the low level, either by your HV calls or by the low level kernel. Always. That's how PCI config space is supposed to work. Ben. ------------------------------------------------------------------------- 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