On Fri, Jun 9, 2023 at 10:53 AM Parav Pandit <[email protected]> wrote: > > > > From: Jason Wang <[email protected]> > > Sent: Thursday, June 8, 2023 10:43 PM > > > > 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) > > > This is what is done in v5.
I meant this could be done with _F_LEGACY_HEADER/MAC as well. > > > 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? > I didn’t follow the question. > > > (Btw, how do > > you define 1.x objects, isn't any facility via adminq an 1.x object?) > > > 1.x objects of the passthrough VF device. > > > 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. > Hypervisor does not involve in feature negotiation and device life cycle > phase so it cannot negotiate it. With _F_LEGACY_HEADER + _F_LEGACY_MAC, hypervisor doesn't need to be involved in the feature negotiation for modern devices as well. Anything I missed? Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
