On Sun, May 21, 2023 at 01:24:55PM +0000, Parav Pandit wrote: > > From: Michael S. Tsirkin <[email protected]> > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
