Re: [Qemu-devel] how Windows treats BARs of driver-less devices when other devices are hotplugged

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Feb 25, 2016 at 06:37:56PM +0100, Laszlo Ersek wrote:
> On 02/25/16 15:18, Michael S. Tsirkin wrote:
> > On Thu, Feb 25, 2016 at 03:05:08PM +0100, Laszlo Ersek wrote:
> >> On 02/25/16 14:30, Michael S. Tsirkin wrote:
> 
> >>> virtio?
> >>
> >> ... was my first thought as well, but OVMF at the moment supports only
> >> legacy (0.9.5) virtio-pci devices
> > 
> > Oh. We'll have to fix that too :(
> 
> Yes, there's a BZ open about it. It's very big work. Due to independent
> reasons, I skimmed the virtio 1.0 spec the other day, specifically for
> seeing what it would take to port the OVMF drivers forward to virtio
> 1.0. It's going to be a *lot* of work.

A hint: review at least cs03 or latest draft csprd05.
First hint on google is ancient draft csprd01.

> >> (and virtio-mmio only on AARCH64) --
> >> those don't have MMIO BARs, only IO BARs.
> > 
> > Well that's not exactly true - there is an MSI-X BAR.
> > Maybe OVMF does not enable that, though.
> 
> Correct.
> 
> The virtio stuff in OVMF adheres extremely closely to the 0.9.5 spec
> (and the actual QEMU code was only studied when the guest wouldn't work
> as described by the 0.9.5 spec -- this usually boiled down to silent
> framing assumptions made by QEMU, and then the guest code was
> accomodated), but the virtio code in OVMF is purposely absolutely
> minimal, feature-wise.
> 
> I also looked up Gerd's virtio 1.0 patch series in the SeaBIOS git
> history (from summer 2015, IIRC). It was extensive. Extrapolating from
> that, you can imagine what it will take for OVMF.
> 
> Thanks
> Laszlo

Basically the same amount as seabios I guess.

-- 
MST