Re: [PATCH 08/11] transport-pci: Introduce virtio extended capability

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

On Sun, May 21, 2023 at 01:24:55PM +0000, Parav Pandit wrote:
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, May 21, 2023 1:58 AM
> 
> > Yes but neither can it support new devices because it does not look for the new
> > device id. So it's fine - I was talking about new devices using extended
> > capability.
> > 
> > We shouldn't just laser-focus on existing software and devices, there's probably
> > more to come.
> >
> Sure, new devices can use new capability.
> I will roll this as separate patch and github issue.
> As we discussed, legacy register access over AQ does not need this capability anyway.
> 
> So not related to v2 discussion.
> I am in middle of splitting this as separate patch unrelated to the v2 for legacy access.
> 
> > 
> > > But that is the case with any existing software, not just seabios.
> > >
> > > New capability is in addition to the existing one.
> > > And code already exists to refer to the old one, so I am not seeing any gain to
> > create them now.
> > > Any new capability that one creates in the future can be in the extended area.
> > 
> > Question is about MCFG in general.  Is adding capability to access MCFG to
> > seabios for pci accesses practical? hard?
> >
> What is MCFG?

This is the name of the ACPI table describing memory mapped pci config
accesses.


> > > You mentioned a perf angle that it takes half the time, but I don't
> > > see how as the only change between legacy and ext is: offset.
> > 
> > For a variety of reasons Linux does not use memory mapped accesses for legacy
> > config space, it uses cf8/cfc for that.
> And does it use memory mapped accesses for non-legacy config space?

No other way to access that, right?

-- 
MST