Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Thu, 12 Jul 2018 21:20:41 -0400 "Samudrala, Sridhar" wrote: > On 7/12/2018 6:19 PM, Siwei Liu wrote: > > On Thu, Jul 12, 2018 at 2:00 PM, Michael S. Tsirkin > > wrote: > >> On Thu, Jul 12, 2018 at 01:52:53PM -0700, Siwei Liu wrote: > >>> The definition is incomplete due to lack of spec. There's no "host" > >>> part defined yet in the host-guest interface. If match by MAC is an > >>> interface, the same must be done on the host(device) side as well, > >>> which has been agreed not the way to go. However, I don't think that's > >>> what the author intends to do by interpreting his QEMU patch - it > >>> missed the other parts as well, such as the feature negotiation and > >>> how it interacts with the paired device. > >>> > >>> What I said is that match by MAC is just a guest implementation that > >>> one can change at any time. We now have the group ID on QEMU, why > >>> still sticking to matching by MAC? It shoulnd't be a host-guest > >>> interface in the first place anyway. > >> I think that match by MAC is a simple portable way to match devices. > >> E.g. it will work seamlessly with niche things like zPCI. However > > That's a good point. I'm not sure if it's a valid assumption that zPCI > > should always use the same MAC address as that of virtio. Someone I think we can mostly disregard the weirdness that is zPCI right now. There should be no fundamental reasons that matching by MAC would not work, though. > > who's more familiar with the use case may decide and work on that. It > > means VFIO device has to take in the MAC address as an identifier to > > the "-device vfio-pci,.." QEMU option. I think there's no point to > > match device using group ID in QEMU while using MAC in the guest. > > Based on that assumption, I'd go with making VIRTIO_NET_F_STANDBY to > > match device based on group ID, while someone may come up with another > > feature bit later, say VIRTIO_NET_F_STANDBY_BY_MAC when its QEMU > > support is available. Would it make sense? > > VIRTIO_NET_F_STANDBY as defined in the guest virtio_net driver supports match > by MAC address. I think we should add support for this feature bit in QEMU. > If submitting a patch to update the spec is a pre-requisite to add this > feature bit to QEMU, i can do that. Doing a spec patch and implementing matching by MAC in QEMU sounds like a good plan to me. > > As far as i understand, group id patches to QEMU are still under review. > Matching by group ID can be another feature bit that could support matching > by group id as well as MAC. That plan sounds good to me as well. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Thu, Jul 12, 2018 at 09:20:41PM -0400, Samudrala, Sridhar wrote: > On 7/12/2018 6:19 PM, Siwei Liu wrote: > > On Thu, Jul 12, 2018 at 2:00 PM, Michael S. Tsirkin wrote: > > > On Thu, Jul 12, 2018 at 01:52:53PM -0700, Siwei Liu wrote: > > > > The definition is incomplete due to lack of spec. There's no "host" > > > > part defined yet in the host-guest interface. If match by MAC is an > > > > interface, the same must be done on the host(device) side as well, > > > > which has been agreed not the way to go. However, I don't think that's > > > > what the author intends to do by interpreting his QEMU patch - it > > > > missed the other parts as well, such as the feature negotiation and > > > > how it interacts with the paired device. > > > > > > > > What I said is that match by MAC is just a guest implementation that > > > > one can change at any time. We now have the group ID on QEMU, why > > > > still sticking to matching by MAC? It shoulnd't be a host-guest > > > > interface in the first place anyway. > > > I think that match by MAC is a simple portable way to match devices. > > > E.g. it will work seamlessly with niche things like zPCI. However > > That's a good point. I'm not sure if it's a valid assumption that zPCI > > should always use the same MAC address as that of virtio. Someone > > who's more familiar with the use case may decide and work on that. It > > means VFIO device has to take in the MAC address as an identifier to > > the "-device vfio-pci,.." QEMU option. I think there's no point to > > match device using group ID in QEMU while using MAC in the guest. > > Based on that assumption, I'd go with making VIRTIO_NET_F_STANDBY to > > match device based on group ID, while someone may come up with another > > feature bit later, say VIRTIO_NET_F_STANDBY_BY_MAC when its QEMU > > support is available. Would it make sense? > > VIRTIO_NET_F_STANDBY as defined in the guest virtio_net driver supports match > by MAC address. I think we should add support for this feature bit in QEMU. > If submitting a patch to update the spec is a pre-requisite to add this > feature bit to QEMU, i can do that. It's not strictly a prerequisite but we need it in spec all the same, so pls do that. > As far as i understand, group id patches to QEMU are still under review. > Matching by group ID can be another feature bit that could support matching > by group id as well as MAC. > > > > -Siwei > > > > > there are other niche use-cases that aren't addressed by match by MAC > > > such as PF pass-through as a primary, and the pci bridge trick addresses > > > that at cost of some portability. > > > > > > So I see no issues supporting both mechanisms, but others on the TC > > > might feel differently. > > > > > > -- > > > MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Thu, Jul 12, 2018 at 2:00 PM, Michael S. Tsirkin wrote: > On Thu, Jul 12, 2018 at 01:52:53PM -0700, Siwei Liu wrote: >> The definition is incomplete due to lack of spec. There's no "host" >> part defined yet in the host-guest interface. If match by MAC is an >> interface, the same must be done on the host(device) side as well, >> which has been agreed not the way to go. However, I don't think that's >> what the author intends to do by interpreting his QEMU patch - it >> missed the other parts as well, such as the feature negotiation and >> how it interacts with the paired device. >> >> What I said is that match by MAC is just a guest implementation that >> one can change at any time. We now have the group ID on QEMU, why >> still sticking to matching by MAC? It shoulnd't be a host-guest >> interface in the first place anyway. > > I think that match by MAC is a simple portable way to match devices. > E.g. it will work seamlessly with niche things like zPCI. However That's a good point. I'm not sure if it's a valid assumption that zPCI should always use the same MAC address as that of virtio. Someone who's more familiar with the use case may decide and work on that. It means VFIO device has to take in the MAC address as an identifier to the "-device vfio-pci,.." QEMU option. I think there's no point to match device using group ID in QEMU while using MAC in the guest. Based on that assumption, I'd go with making VIRTIO_NET_F_STANDBY to match device based on group ID, while someone may come up with another feature bit later, say VIRTIO_NET_F_STANDBY_BY_MAC when its QEMU support is available. Would it make sense? -Siwei > there are other niche use-cases that aren't addressed by match by MAC > such as PF pass-through as a primary, and the pci bridge trick addresses > that at cost of some portability. > > So I see no issues supporting both mechanisms, but others on the TC > might feel differently. > > -- > MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Thu, Jul 12, 2018 at 01:52:53PM -0700, Siwei Liu wrote: > The definition is incomplete due to lack of spec. There's no "host" > part defined yet in the host-guest interface. If match by MAC is an > interface, the same must be done on the host(device) side as well, > which has been agreed not the way to go. However, I don't think that's > what the author intends to do by interpreting his QEMU patch - it > missed the other parts as well, such as the feature negotiation and > how it interacts with the paired device. > > What I said is that match by MAC is just a guest implementation that > one can change at any time. We now have the group ID on QEMU, why > still sticking to matching by MAC? It shoulnd't be a host-guest > interface in the first place anyway. I think that match by MAC is a simple portable way to match devices. E.g. it will work seamlessly with niche things like zPCI. However there are other niche use-cases that aren't addressed by match by MAC such as PF pass-through as a primary, and the pci bridge trick addresses that at cost of some portability. So I see no issues supporting both mechanisms, but others on the TC might feel differently. -- MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
_ On Thu, Jul 12, 2018 at 4:31 AM, Cornelia Huck wrote: > On Thu, 12 Jul 2018 02:37:03 -0700 > Siwei Liu wrote: > >> On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck wrote: >> > On Tue, 10 Jul 2018 17:07:37 -0700 >> > Siwei Liu wrote: >> > >> >> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin >> >> wrote: >> >> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote: >> >> >> The plan is to enable group ID based matching in the first place >> >> >> rather than >> >> >> match by MAC, the latter of which is fragile and problematic. >> >> > >> >> > It isn't all that fragile - hyperv used same for a while, so if someone >> >> > posts working patches with QEMU support but before this grouping stuff, >> >> > I'll happily apply them. >> >> >> >> I wouldn't box the solution to very limited scenario just because of >> >> matching by MAC, the benefit of having generic group ID in the first >> >> place is that we save the effort of maintaining legacy MAC based >> >> pairing that just adds complexity anyway. Currently the VF's MAC >> >> address cannot be changed by either PF or by the guest user is a >> >> severe limitation due to this. The other use case is that PT device >> >> than VF would generally have different MAC than the standby virtio. We >> >> shouldn't limit itself to VF specific scenario from the very >> >> beginning. >> > >> > So, this brings me to a different concern: the semantics of >> > VIRTIO_NET_F_STANDBY. >> > >> > * The currently sole user seems to be the virtio-net Linux driver. >> > * The commit messages, code comments and Documentation/ all talk about >> > matching by MAC. >> > * I could not find any proposed update to the virtio spec. (If there >> > had been an older proposal with a different feature name, it is not >> > discoverable.) >> >> No, there was no such spec patch at all when the Linux patch was >> submitted, hence match by MAC is the only means to pair device due to >> lack of QEMU support. > > We need to know what the device offers if it offers the feature bit, > and what it is supposed to do when the driver negotiates it. Currently, > we can only go by what the Linux driver does and what it expects. IOW, > we need a spec update proposal. Obviously, this should be discussed in > conjunction with the rest. The definition is incomplete due to lack of spec. There's no "host" part defined yet in the host-guest interface. If match by MAC is an interface, the same must be done on the host(device) side as well, which has been agreed not the way to go. However, I don't think that's what the author intends to do by interpreting his QEMU patch - it missed the other parts as well, such as the feature negotiation and how it interacts with the paired device. What I said is that match by MAC is just a guest implementation that one can change at any time. We now have the group ID on QEMU, why still sticking to matching by MAC? It shoulnd't be a host-guest interface in the first place anyway. > >> >> Q: Does it work? >> A: Well, it works for some. >> Q: Does it work well to support all scenarios? >> A: No, not as it claims to. >> Q: Can it do better job to support all scenarios? >> A: Yes, do pairing with the failover group ID instead. >> Q: Does pairing still need to be MAC based if using failover group ID? >> A: It depends, it's up to the implementation to verify MAC address >> depending on the need (e.g. VF failover versus PT device replacement), >> though MAC matching is no longer positioned as a requirement for >> pairing or grouping. > > Whether matching by MAC is good or sufficient is a different > discussion. It is, however, what the code currently *does*, and in > absence of a spec update, it is the only reference for this feature. Not really, it's the same discussion. Before the group ID discussion I explicitly asked for the spec for VIRTIO_NET_F_STANDBY about the semantics. Since no one come up with a spec, I assumed it is still being worked on and it was all right to have the initial Linux implementation to be in. I assume that is a formal process while working on a complicated feature the spec can come later once everything becomes clear along with the discussions. https://www.spinics.net/lists/netdev/msg499011.html I made the same claim at the time that we shouldn't go with what's been implemented in Linux, but instead should look at the entire picture to decide what should be the right semantics for VIRTIO_NET_F_STANDBY. I agree with you we need a spec. I can work on a spec but I'd like to clarify that there was nothing defined yet for VIRTIO_NET_F_STANDBY so it shouldn't be called as spec update. It's still a work-in-progress feature that IMHO it's different than the situation that there used to be pre-spec virtio implementation already working on both host and guest side. The current VIRTIO_NET_F_STANDBY implementation in Linux is pretty much dead code without a spec followed by a host/device side implementation. -Siwei > >> >> There's no such
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Thu, 12 Jul 2018 02:37:03 -0700 Siwei Liu wrote: > On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck wrote: > > On Tue, 10 Jul 2018 17:07:37 -0700 > > Siwei Liu wrote: > > > >> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin > >> wrote: > >> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote: > >> >> The plan is to enable group ID based matching in the first place rather > >> >> than > >> >> match by MAC, the latter of which is fragile and problematic. > >> > > >> > It isn't all that fragile - hyperv used same for a while, so if someone > >> > posts working patches with QEMU support but before this grouping stuff, > >> > I'll happily apply them. > >> > >> I wouldn't box the solution to very limited scenario just because of > >> matching by MAC, the benefit of having generic group ID in the first > >> place is that we save the effort of maintaining legacy MAC based > >> pairing that just adds complexity anyway. Currently the VF's MAC > >> address cannot be changed by either PF or by the guest user is a > >> severe limitation due to this. The other use case is that PT device > >> than VF would generally have different MAC than the standby virtio. We > >> shouldn't limit itself to VF specific scenario from the very > >> beginning. > > > > So, this brings me to a different concern: the semantics of > > VIRTIO_NET_F_STANDBY. > > > > * The currently sole user seems to be the virtio-net Linux driver. > > * The commit messages, code comments and Documentation/ all talk about > > matching by MAC. > > * I could not find any proposed update to the virtio spec. (If there > > had been an older proposal with a different feature name, it is not > > discoverable.) > > No, there was no such spec patch at all when the Linux patch was > submitted, hence match by MAC is the only means to pair device due to > lack of QEMU support. We need to know what the device offers if it offers the feature bit, and what it is supposed to do when the driver negotiates it. Currently, we can only go by what the Linux driver does and what it expects. IOW, we need a spec update proposal. Obviously, this should be discussed in conjunction with the rest. > > Q: Does it work? > A: Well, it works for some. > Q: Does it work well to support all scenarios? > A: No, not as it claims to. > Q: Can it do better job to support all scenarios? > A: Yes, do pairing with the failover group ID instead. > Q: Does pairing still need to be MAC based if using failover group ID? > A: It depends, it's up to the implementation to verify MAC address > depending on the need (e.g. VF failover versus PT device replacement), > though MAC matching is no longer positioned as a requirement for > pairing or grouping. Whether matching by MAC is good or sufficient is a different discussion. It is, however, what the code currently *does*, and in absence of a spec update, it is the only reference for this feature. > > There's no such stickiness for matching by MAC defined anywhere. The > semantics of VIRTIO_NET_F_STANDBY feature are mostly a failover > concept that the standby device should be used when the primary is not > present. We now have added the group ID on QEMU. I don't see why > bothering to get rid of the limitation: it's never been exposed. No > existing users. No API/ABI defined at all. This is scheduled to be released with the next Linux version, which is right now in the -rc phase. It *is* API (a guest <-> host API). No corresponding code is present in QEMU 3.0, which is in freeze right now. Anything that goes into QEMU 3.1 or later needs to accommodate Linux 4.18 as a guest. > > > > > VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no > > official spec, you can only go by the Linux implementation, and by that > > its semantics seem to be 'match by MAC', not 'match by other criteria'. > > > > How is this supposed to work in the long run? > > That group ID thing should work for all OS. Not just Linux. That's exactly my point: We need to care about not-Linux. And about not-QEMU as well. A virtio feature bit should not be defined by what Linux and QEMU do, but needs a real spec. So, currently we have a Linux driver implementation that matches by MAC. If a Linux version with this is released, every device that offers VIRTIO_NET_F_STANDBY needs to support matching by MAC so that this Linux driver will not break. Adding further matching methods should be fine, but might need additional features (needs to be discussed). - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Wed, Jul 11, 2018 at 2:53 AM, Cornelia Huck wrote: > On Tue, 10 Jul 2018 17:07:37 -0700 > Siwei Liu wrote: > >> On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin wrote: >> > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote: >> >> The plan is to enable group ID based matching in the first place rather >> >> than >> >> match by MAC, the latter of which is fragile and problematic. >> > >> > It isn't all that fragile - hyperv used same for a while, so if someone >> > posts working patches with QEMU support but before this grouping stuff, >> > I'll happily apply them. >> >> I wouldn't box the solution to very limited scenario just because of >> matching by MAC, the benefit of having generic group ID in the first >> place is that we save the effort of maintaining legacy MAC based >> pairing that just adds complexity anyway. Currently the VF's MAC >> address cannot be changed by either PF or by the guest user is a >> severe limitation due to this. The other use case is that PT device >> than VF would generally have different MAC than the standby virtio. We >> shouldn't limit itself to VF specific scenario from the very >> beginning. > > So, this brings me to a different concern: the semantics of > VIRTIO_NET_F_STANDBY. > > * The currently sole user seems to be the virtio-net Linux driver. > * The commit messages, code comments and Documentation/ all talk about > matching by MAC. > * I could not find any proposed update to the virtio spec. (If there > had been an older proposal with a different feature name, it is not > discoverable.) No, there was no such spec patch at all when the Linux patch was submitted, hence match by MAC is the only means to pair device due to lack of QEMU support. Q: Does it work? A: Well, it works for some. Q: Does it work well to support all scenarios? A: No, not as it claims to. Q: Can it do better job to support all scenarios? A: Yes, do pairing with the failover group ID instead. Q: Does pairing still need to be MAC based if using failover group ID? A: It depends, it's up to the implementation to verify MAC address depending on the need (e.g. VF failover versus PT device replacement), though MAC matching is no longer positioned as a requirement for pairing or grouping. There's no such stickiness for matching by MAC defined anywhere. The semantics of VIRTIO_NET_F_STANDBY feature are mostly a failover concept that the standby device should be used when the primary is not present. We now have added the group ID on QEMU. I don't see why bothering to get rid of the limitation: it's never been exposed. No existing users. No API/ABI defined at all. > > VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no > official spec, you can only go by the Linux implementation, and by that > its semantics seem to be 'match by MAC', not 'match by other criteria'. > > How is this supposed to work in the long run? That group ID thing should work for all OS. Not just Linux. I will change all the references to MAC matching in my upcoming patch. Thank you for the note. -Siwei - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Tue, 10 Jul 2018 17:07:37 -0700 Siwei Liu wrote: > On Mon, Jul 9, 2018 at 6:54 PM, Michael S. Tsirkin wrote: > > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote: > >> The plan is to enable group ID based matching in the first place rather > >> than > >> match by MAC, the latter of which is fragile and problematic. > > > > It isn't all that fragile - hyperv used same for a while, so if someone > > posts working patches with QEMU support but before this grouping stuff, > > I'll happily apply them. > > I wouldn't box the solution to very limited scenario just because of > matching by MAC, the benefit of having generic group ID in the first > place is that we save the effort of maintaining legacy MAC based > pairing that just adds complexity anyway. Currently the VF's MAC > address cannot be changed by either PF or by the guest user is a > severe limitation due to this. The other use case is that PT device > than VF would generally have different MAC than the standby virtio. We > shouldn't limit itself to VF specific scenario from the very > beginning. So, this brings me to a different concern: the semantics of VIRTIO_NET_F_STANDBY. * The currently sole user seems to be the virtio-net Linux driver. * The commit messages, code comments and Documentation/ all talk about matching by MAC. * I could not find any proposed update to the virtio spec. (If there had been an older proposal with a different feature name, it is not discoverable.) VIRTIO_NET_F_STANDBY is a host <-> guest interface. As there's no official spec, you can only go by the Linux implementation, and by that its semantics seem to be 'match by MAC', not 'match by other criteria'. How is this supposed to work in the long run? - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Mon, Jul 9, 2018 at 6:58 PM, Michael S. Tsirkin wrote: > On Mon, Jul 09, 2018 at 06:11:53PM -0700, si-wei liu wrote: >> What do we buy >> for using a random address during initial discovery and requiring VF to >> complete the handshake? > > I don't see advantages to using a random address that is then > changed either: changing a MAC causes network downtime for most users. > Definitely. I see Linux host stack fundamentally different with Windows, it's non-sense to duplicate what Hyper-V is doing especially if there's no extra benefit. >> Less network downtime during datapath switching? >> Sorry but that's not a key factor at all for our main goal - live migration. > > Isn't avoiding downtime what makes the migration "live"? > If you don't care about it at all just remove the device > and migrate without all these tricks. Apparently this downtime is not avoidable even if guest initiates the switch-over when it is done on Linux host stack. Unless the NIC supports adding duplicate MAC filters with one has higher priority than the other when both are present. I feel there's very little or perhaps zero improvement for the downtime if moving to a guest-initiated datapath switching model. However, since this downtime is intermittent and generally unnoticeable with a few packet drops, network should be resilient in recovering from the drops. My point is that unless we can move to a datapath switching model with zero downtime theoretically, this kind of minor optimization offers very little help in general. Regards, -Siwei > > > -- > MST > > - > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org > - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Fri, 6 Jul 2018 16:37:10 -0700 Siwei Liu wrote: > On Fri, Jul 6, 2018 at 6:54 AM, Cornelia Huck wrote: > > On Thu, 5 Jul 2018 17:49:10 -0700 > > Siwei Liu wrote: > > > >> On Wed, Jul 4, 2018 at 5:15 AM, Cornelia Huck wrote: > >> > On Tue, 3 Jul 2018 16:31:03 -0700 > >> > Siwei Liu wrote: > >> > > >> >> On Tue, Jul 3, 2018 at 7:52 AM, Cornelia Huck > >> >> wrote: > >> >> > From my point of view, there are several concerns: > >> >> > - This approach assumes a homogeneous pairing (same transport), and > >> >> > even more, it assumes that this transport is pci. > >> >> > >> >> Not really. > >> >> > >> >> There could be some other place to define a generic (transport > >> >> independent) virtio feature, whereas the data (group ID) can be stored > >> >> in transport specific way. That generic virtio feature and the way to > >> >> specify target transport to group with is yet to be defined. I don't > >> >> see this patch is in conflict with that direction. > >> > > >> > Sorry, but I really do not see how this is not pci-specific. > >> > > >> > - One of your components is a bridge. A transport does not necessarily > >> > have that concept, at least not in a way meaningful for this approach > >> > to work. > >> > >> Assuming we have a transport agnostic high-level virtio feature to > >> indicate that the target type for the to-be-paired device is PCI, then > >> we have to use the data stored in a PC bridge to pair the device. It > >> does not associate transport of virtio itself with the type of target > >> device, right. The introduction of PCI bridge is just for storing the > >> group ID data for the PCI passthrough device case, while one may > >> define and introduce other means to retrieve the info if target device > >> type is not PCI e.g. a special instruction to get group ID on s390x > >> zPCI. > > > > Well, zPCI *is* PCI, just a very quirky one. I'm not sure how upper > > layers are supposed to distinguish that. > > > > Is there really no existing PCI identifier that (a) the host admin > > already knows and (b) the guest can retrieve easily? > > Not sure if zPCI should be categorized as real PCI due to lack of > topology. Some other virtual PCI or para-virtual PCI buses behave like > PCI but not a full blown one. Those are not regarded as (native) PCI > emulation either. I'm actually close to giving up on zPCI... it is very odd, not publically documented, and I see disk passthrough via vfio-ccw as the more interesting case anyway. > > Can s390x guest use UID and FID described in the blog post you wrote > to identify zPCI device? I am thinking if we can define other grouping > mechanism than the 64bit long group ID (formerly 128 bit UUID). The > high-level indirection not just specifies target transport, but maybe > grouping mechanism also. Not sure if this could work with how they are architected (semantics-wise)... no public documentation is available, so I'll assume we can't use them for another purpose. > > > > >> > >> > - Even if we can introduce transport-specific ways for other > >> > transports, the bridge concept still means that the pairing cannot be > >> > cross-transport. > >> > >> Sorry, I did not get this. A bridge is PCI specific concept indeed, > >> but the virtio iteself can be of other transport. Why it matters? I > >> guess a higher-level feature is needed to define the target transport > >> for the to-be-paired device. The group ID info can reside on the > >> transport specific area on virtio itself though. E.g. for virtio-pci, > >> get it on the vendor specific capability in the PCI configuration > >> space. > >> For virtio-ccw, you may come up with CCW specific way to get the group > >> ID data. Is this not what you had in mind? > > > > No, my idea was it to add it as a field in the virtio-net config space, > > making it transport-agnostic. (And making this a typed value, depending > > on the vfio device we want to pair the virtio device with.) > > > > If we want to extend that to other device types, we can add the field > > in their config space; but I'd rather prefer a more generic "host > > relays config metainformation" approach. > > > >> > >> > > >> > I think we should be clear what we want from a generic > >> > (transport-agnostic) virtio feature first. Probably some way to relay > >> > an identifier of the to-be-paired device (transport-specific + > >> > information what the transport is?) > >> > > >> Are we talking about the transport of the virtio itself or the target > >> device? Note the virtio feature must always be retrieved using > >> transport specific way, although the semantics of the feauture can be > >> transport independent/agnostic. Once a virtio driver instace gets to > >> the point to read feature bits from the device, the transport of that > >> virtio device is determined and cannot be changed later. > > > > No, I don't want to introduce a new, per-transport mechanism, but > > rather put it into the
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Fri, 6 Jul 2018 18:07:00 +0300 "Michael S. Tsirkin" wrote: > On Fri, Jul 06, 2018 at 03:54:06PM +0200, Cornelia Huck wrote: > > On Thu, 5 Jul 2018 17:49:10 -0700 > > Siwei Liu wrote: > > > > > On Wed, Jul 4, 2018 at 5:15 AM, Cornelia Huck wrote: > > > > On Tue, 3 Jul 2018 16:31:03 -0700 > > > > Siwei Liu wrote: > > > > > > > >> On Tue, Jul 3, 2018 at 7:52 AM, Cornelia Huck > > > >> wrote: > > > >> > From my point of view, there are several concerns: > > > >> > - This approach assumes a homogeneous pairing (same transport), and > > > >> > even more, it assumes that this transport is pci. > > > >> > > > >> Not really. > > > >> > > > >> There could be some other place to define a generic (transport > > > >> independent) virtio feature, whereas the data (group ID) can be stored > > > >> in transport specific way. That generic virtio feature and the way to > > > >> specify target transport to group with is yet to be defined. I don't > > > >> see this patch is in conflict with that direction. > > > > > > > > Sorry, but I really do not see how this is not pci-specific. > > > > > > > > - One of your components is a bridge. A transport does not necessarily > > > > have that concept, at least not in a way meaningful for this approach > > > > to work. > > > > > > Assuming we have a transport agnostic high-level virtio feature to > > > indicate that the target type for the to-be-paired device is PCI, then > > > we have to use the data stored in a PC bridge to pair the device. It > > > does not associate transport of virtio itself with the type of target > > > device, right. The introduction of PCI bridge is just for storing the > > > group ID data for the PCI passthrough device case, while one may > > > define and introduce other means to retrieve the info if target device > > > type is not PCI e.g. a special instruction to get group ID on s390x > > > zPCI. > > > > Well, zPCI *is* PCI, just a very quirky one. I'm not sure how upper > > layers are supposed to distinguish that. > > > > Is there really no existing PCI identifier that (a) the host admin > > already knows and (b) the guest can retrieve easily? > > There is e.g. PCI Express serial number. However given that > one use of the feature is for live migration, we really > shouldn't use any ID from a real card. With any "vfio vs. live migration" setup, we basically have two different cases: - Both source and target use the same physical device (device shared between logical partitions, device accessible from two different machines). - We are dealing with two different devices that can be configured to look/act the same. I have been mostly thinking about the first case, but the serial number probably won't work with the second case. > > > > > > > > - Even if we can introduce transport-specific ways for other > > > > transports, the bridge concept still means that the pairing cannot be > > > > cross-transport. > > > > > > Sorry, I did not get this. A bridge is PCI specific concept indeed, > > > but the virtio iteself can be of other transport. Why it matters? I > > > guess a higher-level feature is needed to define the target transport > > > for the to-be-paired device. The group ID info can reside on the > > > transport specific area on virtio itself though. E.g. for virtio-pci, > > > get it on the vendor specific capability in the PCI configuration > > > space. > > > For virtio-ccw, you may come up with CCW specific way to get the group > > > ID data. Is this not what you had in mind? > > > > No, my idea was it to add it as a field in the virtio-net config space, > > making it transport-agnostic. (And making this a typed value, depending > > on the vfio device we want to pair the virtio device with.) > > > > If we want to extend that to other device types, we can add the field > > in their config space; but I'd rather prefer a more generic "host > > relays config metainformation" approach. > > > > > > > > > > > > > I think we should be clear what we want from a generic > > > > (transport-agnostic) virtio feature first. Probably some way to relay > > > > an identifier of the to-be-paired device (transport-specific + > > > > information what the transport is?) > > > > > > > Are we talking about the transport of the virtio itself or the target > > > device? Note the virtio feature must always be retrieved using > > > transport specific way, although the semantics of the feauture can be > > > transport independent/agnostic. Once a virtio driver instace gets to > > > the point to read feature bits from the device, the transport of that > > > virtio device is determined and cannot be changed later. > > > > No, I don't want to introduce a new, per-transport mechanism, but > > rather put it into the config space. > > > > > > > > > >> > - It won't work for zPCI (although zPCI is really strange) -- this > > > >> > means it will be completely unusable on s390x. > > > >> I
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Mon, 9 Jul 2018 16:14:19 +0300 Roman Kagan wrote: > On Fri, Jul 06, 2018 at 03:54:06PM +0200, Cornelia Huck wrote: > > If we want to extend that to other device types, we can add the field > > in their config space; but I'd rather prefer a more generic "host > > relays config metainformation" approach. > > The problem with this approach is that it's too generic and poorly > scoped. As a result I guess it's likely to take ages to converge. I'd certainly not want to wait for it for this particular issue; however, I think there is value in having this (seeing that at least Open Stack and s390x DPM already make use of such a mechanism.) But we can still revisit this later on. (I'm not too sold on branching out to other device types in general, but there seems to be demand for it.) > > See for instance the discussion on including vm config metadata in qcow2 > images: I think it's similar in scope (or the absense thereof). > > Roman. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Fri, Jul 6, 2018 at 6:54 AM, Cornelia Huck wrote: > On Thu, 5 Jul 2018 17:49:10 -0700 > Siwei Liu wrote: > >> On Wed, Jul 4, 2018 at 5:15 AM, Cornelia Huck wrote: >> > On Tue, 3 Jul 2018 16:31:03 -0700 >> > Siwei Liu wrote: >> > >> >> On Tue, Jul 3, 2018 at 7:52 AM, Cornelia Huck wrote: >> >> > From my point of view, there are several concerns: >> >> > - This approach assumes a homogeneous pairing (same transport), and >> >> > even more, it assumes that this transport is pci. >> >> >> >> Not really. >> >> >> >> There could be some other place to define a generic (transport >> >> independent) virtio feature, whereas the data (group ID) can be stored >> >> in transport specific way. That generic virtio feature and the way to >> >> specify target transport to group with is yet to be defined. I don't >> >> see this patch is in conflict with that direction. >> > >> > Sorry, but I really do not see how this is not pci-specific. >> > >> > - One of your components is a bridge. A transport does not necessarily >> > have that concept, at least not in a way meaningful for this approach >> > to work. >> >> Assuming we have a transport agnostic high-level virtio feature to >> indicate that the target type for the to-be-paired device is PCI, then >> we have to use the data stored in a PC bridge to pair the device. It >> does not associate transport of virtio itself with the type of target >> device, right. The introduction of PCI bridge is just for storing the >> group ID data for the PCI passthrough device case, while one may >> define and introduce other means to retrieve the info if target device >> type is not PCI e.g. a special instruction to get group ID on s390x >> zPCI. > > Well, zPCI *is* PCI, just a very quirky one. I'm not sure how upper > layers are supposed to distinguish that. > > Is there really no existing PCI identifier that (a) the host admin > already knows and (b) the guest can retrieve easily? Not sure if zPCI should be categorized as real PCI due to lack of topology. Some other virtual PCI or para-virtual PCI buses behave like PCI but not a full blown one. Those are not regarded as (native) PCI emulation either. Can s390x guest use UID and FID described in the blog post you wrote to identify zPCI device? I am thinking if we can define other grouping mechanism than the 64bit long group ID (formerly 128 bit UUID). The high-level indirection not just specifies target transport, but maybe grouping mechanism also. > >> >> > - Even if we can introduce transport-specific ways for other >> > transports, the bridge concept still means that the pairing cannot be >> > cross-transport. >> >> Sorry, I did not get this. A bridge is PCI specific concept indeed, >> but the virtio iteself can be of other transport. Why it matters? I >> guess a higher-level feature is needed to define the target transport >> for the to-be-paired device. The group ID info can reside on the >> transport specific area on virtio itself though. E.g. for virtio-pci, >> get it on the vendor specific capability in the PCI configuration >> space. >> For virtio-ccw, you may come up with CCW specific way to get the group >> ID data. Is this not what you had in mind? > > No, my idea was it to add it as a field in the virtio-net config space, > making it transport-agnostic. (And making this a typed value, depending > on the vfio device we want to pair the virtio device with.) > > If we want to extend that to other device types, we can add the field > in their config space; but I'd rather prefer a more generic "host > relays config metainformation" approach. > >> >> > >> > I think we should be clear what we want from a generic >> > (transport-agnostic) virtio feature first. Probably some way to relay >> > an identifier of the to-be-paired device (transport-specific + >> > information what the transport is?) >> > >> Are we talking about the transport of the virtio itself or the target >> device? Note the virtio feature must always be retrieved using >> transport specific way, although the semantics of the feauture can be >> transport independent/agnostic. Once a virtio driver instace gets to >> the point to read feature bits from the device, the transport of that >> virtio device is determined and cannot be changed later. > > No, I don't want to introduce a new, per-transport mechanism, but > rather put it into the config space. OK. I think the common understanding is that config space shouldn't be per device type. MST's suggestion in the other mail to carve some space from the device config space for generic use seems viable to me. > >> >> >> >> > - It won't work for zPCI (although zPCI is really strange) -- this >> >> > means it will be completely unusable on s390x. >> >> I still need more information about this use case. First off, does >> >> zPCI support all the hot plug semantics or functionality the same way >> >> as PCI? Or there has to be some platform or firmeware support like >> >> ACPI hotplug? Does QEMU have
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Fri, Jul 06, 2018 at 03:54:06PM +0200, Cornelia Huck wrote: > On Thu, 5 Jul 2018 17:49:10 -0700 > Siwei Liu wrote: > > > On Wed, Jul 4, 2018 at 5:15 AM, Cornelia Huck wrote: > > > On Tue, 3 Jul 2018 16:31:03 -0700 > > > Siwei Liu wrote: > > > > > >> On Tue, Jul 3, 2018 at 7:52 AM, Cornelia Huck wrote: > > >> > > >> > From my point of view, there are several concerns: > > >> > - This approach assumes a homogeneous pairing (same transport), and > > >> > even more, it assumes that this transport is pci. > > >> > > >> Not really. > > >> > > >> There could be some other place to define a generic (transport > > >> independent) virtio feature, whereas the data (group ID) can be stored > > >> in transport specific way. That generic virtio feature and the way to > > >> specify target transport to group with is yet to be defined. I don't > > >> see this patch is in conflict with that direction. > > > > > > Sorry, but I really do not see how this is not pci-specific. > > > > > > - One of your components is a bridge. A transport does not necessarily > > > have that concept, at least not in a way meaningful for this approach > > > to work. > > > > Assuming we have a transport agnostic high-level virtio feature to > > indicate that the target type for the to-be-paired device is PCI, then > > we have to use the data stored in a PC bridge to pair the device. It > > does not associate transport of virtio itself with the type of target > > device, right. The introduction of PCI bridge is just for storing the > > group ID data for the PCI passthrough device case, while one may > > define and introduce other means to retrieve the info if target device > > type is not PCI e.g. a special instruction to get group ID on s390x > > zPCI. > > Well, zPCI *is* PCI, just a very quirky one. I'm not sure how upper > layers are supposed to distinguish that. > > Is there really no existing PCI identifier that (a) the host admin > already knows and (b) the guest can retrieve easily? There is e.g. PCI Express serial number. However given that one use of the feature is for live migration, we really shouldn't use any ID from a real card. > > > > > - Even if we can introduce transport-specific ways for other > > > transports, the bridge concept still means that the pairing cannot be > > > cross-transport. > > > > Sorry, I did not get this. A bridge is PCI specific concept indeed, > > but the virtio iteself can be of other transport. Why it matters? I > > guess a higher-level feature is needed to define the target transport > > for the to-be-paired device. The group ID info can reside on the > > transport specific area on virtio itself though. E.g. for virtio-pci, > > get it on the vendor specific capability in the PCI configuration > > space. > > For virtio-ccw, you may come up with CCW specific way to get the group > > ID data. Is this not what you had in mind? > > No, my idea was it to add it as a field in the virtio-net config space, > making it transport-agnostic. (And making this a typed value, depending > on the vfio device we want to pair the virtio device with.) > > If we want to extend that to other device types, we can add the field > in their config space; but I'd rather prefer a more generic "host > relays config metainformation" approach. > > > > > > > > > I think we should be clear what we want from a generic > > > (transport-agnostic) virtio feature first. Probably some way to relay > > > an identifier of the to-be-paired device (transport-specific + > > > information what the transport is?) > > > > > Are we talking about the transport of the virtio itself or the target > > device? Note the virtio feature must always be retrieved using > > transport specific way, although the semantics of the feauture can be > > transport independent/agnostic. Once a virtio driver instace gets to > > the point to read feature bits from the device, the transport of that > > virtio device is determined and cannot be changed later. > > No, I don't want to introduce a new, per-transport mechanism, but > rather put it into the config space. > > > > > > >> > - It won't work for zPCI (although zPCI is really strange) -- this > > >> > means it will be completely unusable on s390x. > > >> I still need more information about this use case. First off, does > > >> zPCI support all the hot plug semantics or functionality the same way > > >> as PCI? Or there has to be some platform or firmeware support like > > >> ACPI hotplug? Does QEMU have all the pieces ready for s390 zPCI > > >> hotplug? > > > > > > zPCI is a strange beast, so first a pointer to a writeup I did: > > > https://virtualpenguins.blogspot.de/2018/02/notes-on-pci-on-s390x.html > > > > > > It does support hotplug, within the s390 architectural context, but > > > that should be fine for our needs here. > > > > > > My concern comes from the 'no topology' issue. We build a fake topology > > > in QEMU (to use the generic pci infrastructure), but
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Wed, Jul 4, 2018 at 5:15 AM, Cornelia Huck wrote: > On Tue, 3 Jul 2018 16:31:03 -0700 > Siwei Liu wrote: > >> On Tue, Jul 3, 2018 at 7:52 AM, Cornelia Huck wrote: >> > From my point of view, there are several concerns: >> > - This approach assumes a homogeneous pairing (same transport), and >> > even more, it assumes that this transport is pci. >> >> Not really. >> >> There could be some other place to define a generic (transport >> independent) virtio feature, whereas the data (group ID) can be stored >> in transport specific way. That generic virtio feature and the way to >> specify target transport to group with is yet to be defined. I don't >> see this patch is in conflict with that direction. > > Sorry, but I really do not see how this is not pci-specific. > > - One of your components is a bridge. A transport does not necessarily > have that concept, at least not in a way meaningful for this approach > to work. Assuming we have a transport agnostic high-level virtio feature to indicate that the target type for the to-be-paired device is PCI, then we have to use the data stored in a PC bridge to pair the device. It does not associate transport of virtio itself with the type of target device, right. The introduction of PCI bridge is just for storing the group ID data for the PCI passthrough device case, while one may define and introduce other means to retrieve the info if target device type is not PCI e.g. a special instruction to get group ID on s390x zPCI. > - Even if we can introduce transport-specific ways for other > transports, the bridge concept still means that the pairing cannot be > cross-transport. Sorry, I did not get this. A bridge is PCI specific concept indeed, but the virtio iteself can be of other transport. Why it matters? I guess a higher-level feature is needed to define the target transport for the to-be-paired device. The group ID info can reside on the transport specific area on virtio itself though. E.g. for virtio-pci, get it on the vendor specific capability in the PCI configuration space. For virtio-ccw, you may come up with CCW specific way to get the group ID data. Is this not what you had in mind? > > I think we should be clear what we want from a generic > (transport-agnostic) virtio feature first. Probably some way to relay > an identifier of the to-be-paired device (transport-specific + > information what the transport is?) > Are we talking about the transport of the virtio itself or the target device? Note the virtio feature must always be retrieved using transport specific way, although the semantics of the feauture can be transport independent/agnostic. Once a virtio driver instace gets to the point to read feature bits from the device, the transport of that virtio device is determined and cannot be changed later. >> > - It won't work for zPCI (although zPCI is really strange) -- this >> > means it will be completely unusable on s390x. >> I still need more information about this use case. First off, does >> zPCI support all the hot plug semantics or functionality the same way >> as PCI? Or there has to be some platform or firmeware support like >> ACPI hotplug? Does QEMU have all the pieces ready for s390 zPCI >> hotplug? > > zPCI is a strange beast, so first a pointer to a writeup I did: > https://virtualpenguins.blogspot.de/2018/02/notes-on-pci-on-s390x.html > > It does support hotplug, within the s390 architectural context, but > that should be fine for our needs here. > > My concern comes from the 'no topology' issue. We build a fake topology > in QEMU (to use the generic pci infrastructure), but the guest does not > see any of this. It issues an instruction and gets a list of functions. > This means any bridge information is not accessible to the guest. That is the reason why I prefer leaving it to specific transport (zPCI) to define its own means to present and retrieve the group ID information. The high-level feature bit just provides the indirection to the target transport (for the to-be-paired device), while seperate transport can have a way of its own to present/retrieve the group ID data. I don't know where to present that group ID data on s390 zPCI though to be honest. But I doubt we can come up with a very general transport-agnostic way to present the data for both (and pontentially ALL) bus architectures. -Siwei > >> >> Does the s390x use case in your mind concerns with VFIO migraition, or >> replacement of a PT device with backup virtio-ccw path? Or something >> else? > > Migration with vfio is the case most likely to be relevant. I'm mostly > concerned with not needlessly closing doors, though. > >> >> As the assumption of SR-IOV migration is that, hotplug is used as an >> inidicator for datapath switch - which maps to moving MAC address or >> VLAN filter around between PV and VF. I am not sure how that maps to >> s390x and zPCI with regard to host coordination. > > If we can move MAC addresses or VLAN filters on
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Tue, 3 Jul 2018 16:31:03 -0700 Siwei Liu wrote: > On Tue, Jul 3, 2018 at 7:52 AM, Cornelia Huck wrote: > > From my point of view, there are several concerns: > > - This approach assumes a homogeneous pairing (same transport), and > > even more, it assumes that this transport is pci. > > Not really. > > There could be some other place to define a generic (transport > independent) virtio feature, whereas the data (group ID) can be stored > in transport specific way. That generic virtio feature and the way to > specify target transport to group with is yet to be defined. I don't > see this patch is in conflict with that direction. Sorry, but I really do not see how this is not pci-specific. - One of your components is a bridge. A transport does not necessarily have that concept, at least not in a way meaningful for this approach to work. - Even if we can introduce transport-specific ways for other transports, the bridge concept still means that the pairing cannot be cross-transport. I think we should be clear what we want from a generic (transport-agnostic) virtio feature first. Probably some way to relay an identifier of the to-be-paired device (transport-specific + information what the transport is?) > > - It won't work for zPCI (although zPCI is really strange) -- this > > means it will be completely unusable on s390x. > I still need more information about this use case. First off, does > zPCI support all the hot plug semantics or functionality the same way > as PCI? Or there has to be some platform or firmeware support like > ACPI hotplug? Does QEMU have all the pieces ready for s390 zPCI > hotplug? zPCI is a strange beast, so first a pointer to a writeup I did: https://virtualpenguins.blogspot.de/2018/02/notes-on-pci-on-s390x.html It does support hotplug, within the s390 architectural context, but that should be fine for our needs here. My concern comes from the 'no topology' issue. We build a fake topology in QEMU (to use the generic pci infrastructure), but the guest does not see any of this. It issues an instruction and gets a list of functions. This means any bridge information is not accessible to the guest. > > Does the s390x use case in your mind concerns with VFIO migraition, or > replacement of a PT device with backup virtio-ccw path? Or something > else? Migration with vfio is the case most likely to be relevant. I'm mostly concerned with not needlessly closing doors, though. > > As the assumption of SR-IOV migration is that, hotplug is used as an > inidicator for datapath switch - which maps to moving MAC address or > VLAN filter around between PV and VF. I am not sure how that maps to > s390x and zPCI with regard to host coordination. If we can move MAC addresses or VLAN filters on Linux/QEMU/libvirt in general, there's no inherent reason why we shouldn't be able to do so on s390 as well. What matters more is probably which pci network cards are supported (currently Mellanox AFAIK, not sure if there are others). > > -Siwei > > > - It is too focused on a narrow use case. How is it supposed to be > > extended? > > > > What I would prefer: > > - Implement a pairing id support that does not rely on a certain > > transport, but leverages virtio (which is in the game anyway). We'd > > get at least the "virtio-net device paired with vfio" use case, which > > is what is currently implemented in the Linux kernel. > > - Think about a more generic way to relay configuration metadata to the > > host. > > > > - > > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org > > - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Tue, Jul 3, 2018 at 7:52 AM, Cornelia Huck wrote: > On Tue, 3 Jul 2018 09:28:17 -0500 > Venu Busireddy wrote: > >> On 2018-07-03 12:58:25 +0300, Roman Kagan wrote: >> > On Mon, Jul 02, 2018 at 02:14:52PM -0700, si-wei liu wrote: >> > > On 7/2/2018 9:14 AM, Roman Kagan wrote: >> > > > Is the scheme going to be applied/extended to other transports (vmbus, >> > > > virtio-ccw, etc.)? >> > > Well, it depends on the use case, and how feasible it can be extended to >> > > other transport due to constraints and transport specifics. >> > > >> > > > Is the failover group concept going to be used beyond PT-PV network >> > > > device failover? >> > > Although the concept of failover group is generic, the implementation >> > > itself >> > > may vary. >> > >> > My point with these two questions is that since this patchset is >> > defining external interfaces -- with guest OS, with management layer -- >> >> This patch set is not defining any external interfaces. All this is doing >> is provide the means and locations to store the "group identifier". How >> that info will be used, I thought, should be another patch set. >> >> Venu >> >> > which are not easy to change later, it might make sense to try and see >> > if the interfaces map to other usecases. E.g. I think we can get enough >> > information on how Hyper-V handles PT-PV network device failover from >> > the current Linux implementation; it may be a good idea to share some >> > concepts and workflows with virtio-pci. > > But this patch set defines a host<->guest interface to make pairing > information on the host available to the guest, no? > > From my point of view, there are several concerns: > - This approach assumes a homogeneous pairing (same transport), and > even more, it assumes that this transport is pci. Not really. There could be some other place to define a generic (transport independent) virtio feature, whereas the data (group ID) can be stored in transport specific way. That generic virtio feature and the way to specify target transport to group with is yet to be defined. I don't see this patch is in conflict with that direction. > - It won't work for zPCI (although zPCI is really strange) -- this > means it will be completely unusable on s390x. I still need more information about this use case. First off, does zPCI support all the hot plug semantics or functionality the same way as PCI? Or there has to be some platform or firmeware support like ACPI hotplug? Does QEMU have all the pieces ready for s390 zPCI hotplug? Does the s390x use case in your mind concerns with VFIO migraition, or replacement of a PT device with backup virtio-ccw path? Or something else? As the assumption of SR-IOV migration is that, hotplug is used as an inidicator for datapath switch - which maps to moving MAC address or VLAN filter around between PV and VF. I am not sure how that maps to s390x and zPCI with regard to host coordination. -Siwei > - It is too focused on a narrow use case. How is it supposed to be > extended? > > What I would prefer: > - Implement a pairing id support that does not rely on a certain > transport, but leverages virtio (which is in the game anyway). We'd > get at least the "virtio-net device paired with vfio" use case, which > is what is currently implemented in the Linux kernel. > - Think about a more generic way to relay configuration metadata to the > host. > > - > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org > - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
