[ipxe-devel] [PATCH 4/4] [virtio] Add virtio-net 1.0 support

Ladi Prosek lprosek at redhat.com
Fri Mar 11 13:23:31 UTC 2016


On Fri, Mar 11, 2016 at 2:09 PM, Michael S. Tsirkin <mst at redhat.com> wrote:
> On Fri, Mar 11, 2016 at 02:43:23AM +0200, Michael S. Tsirkin wrote:
>> On Thu, Mar 10, 2016 at 04:04:31PM +0100, Ladi Prosek wrote:
>> > On Thu, Mar 10, 2016 at 3:12 PM, Michael S. Tsirkin <mst at redhat.com> wrote:
>> > > On Wed, Mar 09, 2016 at 07:20:03PM +0100, Ladi Prosek wrote:
>> > >> +     /* Enable PCI bus master and reset NIC */
>> > >> +     adjust_pci_device ( pci );
>> > >
>> > > At the moment, this enables memory and io unconditionally.  But I think
>> > > it should check BAR is assigned before enabling and using it, since
>> > > e.g. pci express devices might not have their BARs assigned.
>> > >
>> > > I'm also not sure 64 bit BAR values will work under ipxe -
>> > > if not it's preferably to fall back on io or cfg access.
>> >
>> > Hmm.. 64-bit BARs are indeed not supported. It would be better to
>> > always use the cfg cap then and remove all that BAR mapping business.
>> > Less code and fewer assumptions for the win.
>>
>> Much slower though.
>
> Thinking more about it, I think it's a good idea to
> leave the mapping infrastructure in place, but
> maybe only do the CFG approach as the first step.
>
> Once code is upstream and works, we can add
> faster BAR/IO support later.

Apologies for a naive question: since we need a 64-bit iPXE build for
proper 64-bit BAR support, does it mean that we would have to ship two
.rom files with QEMU, one for 32-bit guests and one for 64-bit guests?

> Cc Gerd who worked on similar issues for virtio blk.
>
> Gerd, what did you do there?
>
>> > > --
>> > > MST



More information about the ipxe-devel mailing list