From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Martin Subject: Re: Realtime access to PCI NIC Date: Thu, 10 Jul 2014 08:47:24 +0100 Message-ID: <11710529870.20140710084724@gmail.com> References: <524794479.20140703121338@gmail.com> <20140703180957.GD13710@konrad-lan.dumpdata.com> <1376452421.20140707092147@gmail.com> <1083121389.20140707122233@gmail.com> <724187406.20140707132106@gmail.com> <1404830785.24591.2.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1404830785.24591.2.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Thanks Ian, Tuesday, July 8, 2014, 3:46:25 PM, you wrote: > Only PCI cfg reads/writes go via the backend, I think. Any MMIO space > (i.e. described in the PCI BARS) can be directly mapped, likewise for > the IO port spaces associated with the device. > I think PCI cfg space is only generally used during probing/setup etc. > Hopefully you don't need to poke it at runtime? You have confirmed the conclusion that I was coming to! > Right, VT-d allows the MMIO stuff to be mapped to an HVM guest (PV > doesn't even need that), but unfortunately there are bits in the pci cfg > space which even a guest with the device passed to it shouldn't be able > to mess with (I don't know the details though). Perfect. -- Best regards, Simon mailto:furryfuttock@gmail.com