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
[virtio-dev] Re: [PATCH net-next v2 0/5] virtio: support packed ring
On Thu, Jul 12, 2018 at 02:44:58PM -0700, David Miller wrote: > From: Tiwei Bie > Date: Wed, 11 Jul 2018 10:27:06 +0800 > > > Hello everyone, > > > > This patch set implements packed ring support in virtio driver. > > > > Some functional tests have been done with Jason's > > packed ring implementation in vhost: > > > > https://lkml.org/lkml/2018/7/3/33 > > > > Both of ping and netperf worked as expected. > > Michael and Jason, where are we with this series? I'm at netdev, won't be able to review before Monday. -- 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 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. 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
[virtio-dev] Re: [PATCH net-next v2 0/5] virtio: support packed ring
On 2018年07月13日 05:44, David Miller wrote: From: Tiwei Bie Date: Wed, 11 Jul 2018 10:27:06 +0800 Hello everyone, This patch set implements packed ring support in virtio driver. Some functional tests have been done with Jason's packed ring implementation in vhost: https://lkml.org/lkml/2018/7/3/33 Both of ping and netperf worked as expected. Michael and Jason, where are we with this series? For the series: Acked-by: Jason Wang - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v35 1/5] mm: support to get hints of free page blocks
On 07/12/2018 07:49 PM, Michal Hocko wrote: On Thu 12-07-18 19:34:16, Wei Wang wrote: On 07/12/2018 04:13 PM, Michal Hocko wrote: On Thu 12-07-18 10:52:08, Wei Wang wrote: On 07/12/2018 10:30 AM, Linus Torvalds wrote: On Wed, Jul 11, 2018 at 7:17 PM Wei Wang wrote: Would it be better to remove __GFP_THISNODE? We actually want to get all the guest free pages (from all the nodes). Maybe. Or maybe it would be better to have the memory balloon logic be per-node? Maybe you don't want to remove too much memory from one node? I think it's one of those "play with it" things. I don't think that's the big issue, actually. I think the real issue is how to react quickly and gracefully to "oops, I'm trying to give memory away, but now the guest wants it back" while you're in the middle of trying to create that 2TB list of pages. OK. virtio-balloon has already registered an oom notifier (virtballoon_oom_notify). I plan to add some control there. If oom happens, - stop the page allocation; - immediately give back the allocated pages to mm. Please don't. Oom notifier is an absolutely hideous interface which should go away sooner or later (I would much rather like the former) so do not build a new logic on top of it. I would appreciate if you actually remove the notifier much more. You can give memory back from the standard shrinker interface. If we are reaching low reclaim priorities then we are struggling to reclaim memory and then you can start returning pages back. OK. Just curious why oom notifier is thought to be hideous, and has it been a consensus? Because it is a completely non-transparent callout from the OOM context which is really subtle on its own. It is just too easy to end up in weird corner cases. We really have to be careful and be as swift as possible. Any potential sleep would make the OOM situation much worse because nobody would be able to make a forward progress or (in)direct dependency on MM subsystem can easily deadlock. Those are really hard to track down and defining the notifier as blockable by design which just asks for bad implementations because most people simply do not realize how subtle the oom context is. Another thing is that it happens way too late when we have basically reclaimed the world and didn't get out of the memory pressure so you can expect any workload is suffering already. Anybody sitting on a large amount of reclaimable memory should have released that memory by that time. Proportionally to the reclaim pressure ideally. The notifier API is completely unaware of oom constrains. Just imagine you are OOM in a subset of numa nodes. Callback doesn't have any idea about that. Moreover we do have proper reclaim mechanism that has a feedback loop and that should be always preferable to an abrupt reclaim. Sounds very reasonable, thanks for the elaboration. I'll try with shrinker. Best, Wei - 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
[virtio-dev] Re: [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
On Tue, Jul 10, 2018 at 09:28:57AM -0500, Venu Busireddy wrote: > On 2018-07-10 05:11:18 +0300, Michael S. Tsirkin wrote: > > On Fri, Jun 29, 2018 at 05:19:03PM -0500, Venu Busireddy wrote: > > > The current patch set includes all the feedback received for proposals [3] > > > and [4]. For the sake of completeness, patch for the virtio specification > > > is also included here. Following is the updated proposal. > > > > > > 1. Extend the virtio specification to include a new virtio PCI capability > > >"VIRTIO_PCI_CAP_GROUP_ID_CFG". > > > > > > > > > default-configs/arm-softmmu.mak | 1 + > > > default-configs/i386-softmmu.mak| 1 + > > > default-configs/x86_64-softmmu.mak | 1 + > > > hw/pci-bridge/Makefile.objs | 1 + > > > hw/pci-bridge/pci_bridge_dev.c | 10 + > > > hw/pci-bridge/pcie_downstream.c | 220 > > > hw/pci-bridge/pcie_downstream.h | 10 + > > > hw/pci/pci_bridge.c | 34 +++ > > > hw/virtio/virtio-pci.c | 15 ++ > > > hw/virtio/virtio-pci.h | 3 +- > > > include/hw/pci/pci.h| 37 ++-- > > > include/hw/pci/pci_bridge.h | 2 + > > > include/hw/pci/pcie.h | 1 + > > > include/standard-headers/linux/virtio_pci.h | 8 + > > > 14 files changed, 326 insertions(+), 18 deletions(-) > > > create mode 100644 hw/pci-bridge/pcie_downstream.c > > > create mode 100644 hw/pci-bridge/pcie_downstream.h > > > > I don't see the spec patch here. > > Since the spec patch is in a different repo, I could not get 'git > format-patch' to combine them together. As a result, I added the spec > patch itself to the patches, but it is not in the cover letter. > > I can combine them manually, and repost. Do you want me do that? > > Thanks, > > Venu It's ok, I found it now. -- 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 sticki
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 11:53:44AM +0200, 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.) > > 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? We definitely need a spec patch for VIRTIO_NET_F_STANDBY documenting existing semantics. Sridhar, do you plan to take a look? -- 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, 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
[virtio-dev] Re: [PATCH v35 1/5] mm: support to get hints of free page blocks
On 07/12/2018 04:13 PM, Michal Hocko wrote: On Thu 12-07-18 10:52:08, Wei Wang wrote: On 07/12/2018 10:30 AM, Linus Torvalds wrote: On Wed, Jul 11, 2018 at 7:17 PM Wei Wang wrote: Would it be better to remove __GFP_THISNODE? We actually want to get all the guest free pages (from all the nodes). Maybe. Or maybe it would be better to have the memory balloon logic be per-node? Maybe you don't want to remove too much memory from one node? I think it's one of those "play with it" things. I don't think that's the big issue, actually. I think the real issue is how to react quickly and gracefully to "oops, I'm trying to give memory away, but now the guest wants it back" while you're in the middle of trying to create that 2TB list of pages. OK. virtio-balloon has already registered an oom notifier (virtballoon_oom_notify). I plan to add some control there. If oom happens, - stop the page allocation; - immediately give back the allocated pages to mm. Please don't. Oom notifier is an absolutely hideous interface which should go away sooner or later (I would much rather like the former) so do not build a new logic on top of it. I would appreciate if you actually remove the notifier much more. You can give memory back from the standard shrinker interface. If we are reaching low reclaim priorities then we are struggling to reclaim memory and then you can start returning pages back. OK. Just curious why oom notifier is thought to be hideous, and has it been a consensus? Best, Wei - 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
