On Fri, Jun 9, 2023 at 10:29 AM Parav Pandit <[email protected]> wrote: > > > > From: Jason Wang <[email protected]> > > Sent: Thursday, June 8, 2023 10:07 PM > > > I think not since you fail to explain why this approach is better than > > simply > > adding new features like _F_LEGACY_HEADER and _F_LEGACY_MAC. > > Please refer back to the requirements of cover letter and multiple past > discussions. > And Michael also explained... > > It is passthrough device, none of the 1.x objects are accessible or mediated > by the hypervisor.
Let me quote my reply once again: " Hypervisor just need to prepare 1) legacy BAR with legacy config and device configuration space 2) modern BAR with modern capabilities (common cfg and device cfg) For 2) it could be mapped directly to guest without any mediation For 1) hypervisor needs to mediate " There's zero mediation for 1.x objects at all. No? For accessing 1.x objects by hypervisor, what's wrong with that especially considering it is used for legacy mediation only but not modern? (Btw, how do you define 1.x objects, isn't any facility via adminq an 1.x object?) In order to converge the discussion, maybe you can explain which one of your 3 use cases and why can't work with _F_LEGACY_HEADER + _F_LEGACY_MAC. Thanks > > Cannot repeat more. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
