From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH RFC] virtio-pci: new config layout: using memory BAR Date: Thu, 06 Jun 2013 10:02:14 -0500 Message-ID: <871u8fp9jd.fsf@codemonkey.ws> References: <87ehcgr3wq.fsf@codemonkey.ws> <20130605151953.GA25987@redhat.com> <87bo7ktvaw.fsf@codemonkey.ws> <20130605162029.GB26561@redhat.com> <51AFA92B.2030203@zytor.com> <87fvwwmdmf.fsf@codemonkey.ws> <51AFB3DD.1050902@zytor.com> <874ndcb47i.fsf@codemonkey.ws> <51AFC4A6.6070607@zytor.com> <877gi8nk9e.fsf@codemonkey.ws> <20130606063432.GQ4725@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "H. Peter Anvin" , Peter Maydell , kvm@vger.kernel.org, "Michael S. Tsirkin" , virtualization@lists.linux-foundation.org, Stefan Hajnoczi , Paolo Bonzini , KONRAD Frederic To: Gleb Natapov Return-path: Received: from e9.ny.us.ibm.com ([32.97.182.139]:49993 "EHLO e9.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751331Ab3FFPCi (ORCPT ); Thu, 6 Jun 2013 11:02:38 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 6 Jun 2013 11:02:37 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3BC0F38C8059 for ; Thu, 6 Jun 2013 11:02:33 -0400 (EDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r56F2Wb0263130 for ; Thu, 6 Jun 2013 11:02:33 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r56F2Plm001890 for ; Thu, 6 Jun 2013 09:02:28 -0600 In-Reply-To: <20130606063432.GQ4725@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov writes: > On Wed, Jun 05, 2013 at 07:41:17PM -0500, Anthony Liguori wrote: >> "H. Peter Anvin" writes: >> >> > On 06/05/2013 03:08 PM, Anthony Liguori wrote: >> >>> >> >>> Definitely an option. However, we want to be able to boot from native >> >>> devices, too, so having an I/O BAR (which would not be used by the OS >> >>> driver) should still at the very least be an option. >> >> >> >> What makes it so difficult to work with an MMIO bar for PCI-e? >> >> >> >> With legacy PCI, tracking allocation of MMIO vs. PIO is pretty straight >> >> forward. Is there something special about PCI-e here? >> >> >> > >> > It's not tracking allocation. It is that accessing memory above 1 MiB >> > is incredibly painful in the BIOS environment, which basically means >> > MMIO is inaccessible. >> >> Oh, you mean in real mode. >> >> SeaBIOS runs the virtio code in 32-bit mode with a flat memory layout. >> There are loads of ASSERT32FLAT()s in the code to make sure of this. >> > Well, not exactly. Initialization is done in 32bit, but disk > reads/writes are done in 16bit mode since it should work from int13 > interrupt handler. The only way I know to access MMIO bars from 16 bit > is to use SMM which we do not have in KVM. Ah, if it's just the dataplane operations then there's another solution. We can introduce a virtqueue flag that asks the backend to poll for new requests. Then SeaBIOS can add the request to the queue and not worry about kicking or reading the ISR. SeaBIOS is polling for completion anyway. Regards, Anthony Liguori > > -- > Gleb. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html