Re: [Qemu-devel] net: Next steps to deprecate -net
On Wed, Jul 22, 2015 at 03:40:55PM +0200, Markus Armbruster wrote: Copying Andreas just in case. Thomas Huth th...@redhat.com writes: On 07/17/2015 09:25 AM, Peter Maydell wrote: On 17 July 2015 at 07:53, Thomas Huth th...@redhat.com wrote: Ok, assuming that my Network traffic dumping for -netdev devices patch series is going to solve the dumping-for-netdev problem, how do we tackle the remaining problems that we have to solve before we can deprecate -net? Does anybody have a survey of the (onboard) NICs that can only be configured with -net but not with -device? Could they nowadays be changed to work with -device, too, or are there still major obstacles to solve first? The problem is that -device says create a new device and configure it like this. But onboard NICs are created by the board, so we want let the user say how to configure those devices, not create new ones... The more general problem is lack of a uniform way to configure onboard devices. We have a bunch of ways to configure onboard devices: -net nic, -serial, -parallel, -drive, ... These all deposit configuration requests in well-known places for the board code to pick up. A request can apply (a) to a mandatory onboard device, modifying its configuration, or (b) to an optional onboard device, triggering its creation, or (c) to nothing in particular. It all depends on the board code. For qdevified devices, you can replace (b) with -device, but not (a), as Peter points out. To likewise replace (a), we'd need means to change an *existing* device's properties. Complication: how to address the device. Onboard devices don't have a qdev ID... QOM path? Aside: you can sometimes use -global to replace (a), but it's not general, because -global applies to all devices of a certain type, not just the one you're actually targeting. Ok, I see ... maybe it makes sense to simply keep -net nic to be able to configure the default/onboard NIC, and only to remove all the other -net options instead (-net user etc.). The disliked vlan/hub concept could then be removed, too, since -net nic can be used together with -netdev nowadays by using something like -net nic,netdev=xxx as far as I know. That would clean up most points of confusion, I think, and would not cause too much code churn for the onboard NICs. Does that sound feasible? Deprecating -net except for -net nic sounds like a fine step forward to me. -net dump is also useful, we'll need some solution for that if we want to deprecate vlans. -- MST
Re: [Qemu-devel] net: Next steps to deprecate -net
On 22/07/15 18:20, Michael S. Tsirkin wrote: On Wed, Jul 22, 2015 at 03:40:55PM +0200, Markus Armbruster wrote: ... Deprecating -net except for -net nic sounds like a fine step forward to me. -net dump is also useful, we'll need some solution for that if we want to deprecate vlans. *cough* see my patch series at: http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg02771.html Thomas
Re: [Qemu-devel] net: Next steps to deprecate -net
Copying Andreas just in case. Thomas Huth th...@redhat.com writes: On 07/17/2015 09:25 AM, Peter Maydell wrote: On 17 July 2015 at 07:53, Thomas Huth th...@redhat.com wrote: Ok, assuming that my Network traffic dumping for -netdev devices patch series is going to solve the dumping-for-netdev problem, how do we tackle the remaining problems that we have to solve before we can deprecate -net? Does anybody have a survey of the (onboard) NICs that can only be configured with -net but not with -device? Could they nowadays be changed to work with -device, too, or are there still major obstacles to solve first? The problem is that -device says create a new device and configure it like this. But onboard NICs are created by the board, so we want let the user say how to configure those devices, not create new ones... The more general problem is lack of a uniform way to configure onboard devices. We have a bunch of ways to configure onboard devices: -net nic, -serial, -parallel, -drive, ... These all deposit configuration requests in well-known places for the board code to pick up. A request can apply (a) to a mandatory onboard device, modifying its configuration, or (b) to an optional onboard device, triggering its creation, or (c) to nothing in particular. It all depends on the board code. For qdevified devices, you can replace (b) with -device, but not (a), as Peter points out. To likewise replace (a), we'd need means to change an *existing* device's properties. Complication: how to address the device. Onboard devices don't have a qdev ID... QOM path? Aside: you can sometimes use -global to replace (a), but it's not general, because -global applies to all devices of a certain type, not just the one you're actually targeting. Ok, I see ... maybe it makes sense to simply keep -net nic to be able to configure the default/onboard NIC, and only to remove all the other -net options instead (-net user etc.). The disliked vlan/hub concept could then be removed, too, since -net nic can be used together with -netdev nowadays by using something like -net nic,netdev=xxx as far as I know. That would clean up most points of confusion, I think, and would not cause too much code churn for the onboard NICs. Does that sound feasible? Deprecating -net except for -net nic sounds like a fine step forward to me.
Re: [Qemu-devel] net: Next steps to deprecate -net
On 07/17/2015 09:25 AM, Peter Maydell wrote: On 17 July 2015 at 07:53, Thomas Huth th...@redhat.com wrote: Ok, assuming that my Network traffic dumping for -netdev devices patch series is going to solve the dumping-for-netdev problem, how do we tackle the remaining problems that we have to solve before we can deprecate -net? Does anybody have a survey of the (onboard) NICs that can only be configured with -net but not with -device? Could they nowadays be changed to work with -device, too, or are there still major obstacles to solve first? The problem is that -device says create a new device and configure it like this. But onboard NICs are created by the board, so we want let the user say how to configure those devices, not create new ones... Ok, I see ... maybe it makes sense to simply keep -net nic to be able to configure the default/onboard NIC, and only to remove all the other -net options instead (-net user etc.). The disliked vlan/hub concept could then be removed, too, since -net nic can be used together with -netdev nowadays by using something like -net nic,netdev=xxx as far as I know. That would clean up most points of confusion, I think, and would not cause too much code churn for the onboard NICs. Does that sound feasible? Thomas signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too)
On Fri, Jul 17, 2015 at 08:53:08AM +0200, Thomas Huth wrote: On 05/26/2015 04:29 PM, Markus Armbruster wrote: Stefan Hajnoczi stefa...@redhat.com writes: [...] We thought the QEMU vlan concept would be dropped completely in the future, so it was never added to -netdev. No patches to do that have been posted over the years, so I think it was more of a conceptual goal than a concrete requirement. Well, patches to do that first need to replace the VLAN-only dump feature. To fully deprecate -net, we also have to replace -net nic for configuring onboard NICs. Prior discussion: http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html We haven't really tried either. Ok, assuming that my Network traffic dumping for -netdev devices patch series is going to solve the dumping-for-netdev problem, how do we tackle the remaining problems that we have to solve before we can deprecate -net? Does anybody have a survey of the (onboard) NICs that can only be configured with -net but not with -device? Could they nowadays be changed to work with -device, too, or are there still major obstacles to solve first? Take a look at nd_table[] and nb_nics. That's the array of -net nic devices. The boards look into the array to grab NICs. The default NIC is set in net_init_clients() as a -net nic option. The weird thing about -net nic is that the device is not created in net/net.c by the -net nic command-line option. It just adds the information to the nd_table[] array. It's the board that has to instantiate nd_table[] entries. For example, pc_nic_init() adds devices for x86 guests. That's about all I know or have thought about so far. It would be nice to get rid of -net but it will take some work and is a QEMU 3.0 feature since it breaks backwards compatibility. pgp0U_M3wqYnm.pgp Description: PGP signature
Re: [Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too)
On 17 July 2015 at 07:53, Thomas Huth th...@redhat.com wrote: Ok, assuming that my Network traffic dumping for -netdev devices patch series is going to solve the dumping-for-netdev problem, how do we tackle the remaining problems that we have to solve before we can deprecate -net? Does anybody have a survey of the (onboard) NICs that can only be configured with -net but not with -device? Could they nowadays be changed to work with -device, too, or are there still major obstacles to solve first? The problem is that -device says create a new device and configure it like this. But onboard NICs are created by the board, so we want let the user say how to configure those devices, not create new ones... -- PMM
[Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too)
On 05/26/2015 04:29 PM, Markus Armbruster wrote: Stefan Hajnoczi stefa...@redhat.com writes: [...] We thought the QEMU vlan concept would be dropped completely in the future, so it was never added to -netdev. No patches to do that have been posted over the years, so I think it was more of a conceptual goal than a concrete requirement. Well, patches to do that first need to replace the VLAN-only dump feature. To fully deprecate -net, we also have to replace -net nic for configuring onboard NICs. Prior discussion: http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html We haven't really tried either. Ok, assuming that my Network traffic dumping for -netdev devices patch series is going to solve the dumping-for-netdev problem, how do we tackle the remaining problems that we have to solve before we can deprecate -net? Does anybody have a survey of the (onboard) NICs that can only be configured with -net but not with -device? Could they nowadays be changed to work with -device, too, or are there still major obstacles to solve first? Thomas signature.asc Description: OpenPGP digital signature
