[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] how Windows treats BARs of driver-less devices when oth
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] how Windows treats BARs of driver-less devices when other devices are hotplugged |
Date: |
Thu, 25 Feb 2016 21:44:44 +0200 |
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