|
From: | Michal Novotny |
Subject: | [Qemu-devel] Re: [PATCH] Make NIC model fallback to default when specified model is not supported |
Date: | Tue, 21 Sep 2010 09:10:37 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 |
On 09/20/2010 07:58 PM, Michael S. Tsirkin wrote:
On Mon, Sep 20, 2010 at 11:47:59AM +0200, Michal Novotny wrote:Hi, this is the patch to introduce a NIC model fallback to default when model specified is not supported. It's been tested on i386-softmmu target on i386 host using the Windows XP x86 virtual machine and by trying to setup the invalid (unsupported) model of NIC device. Also, the new constant in the net.h called the DEFAULT_NIC_MODEL has been introduced to be able to change the default NIC model easily. This variable is being used to set the default NIC model when necessary.Why is this a good idea? This will create problems for anyone doing migration, etc.
Why do you think it would introduce issues when doing migrations? Imagine one version (v1) of qemu supporting NIC model called e.g. "model" but the newer version (v2) no longer supporting the model and you migrate a guest from v1 to v2 that's using "model" NIC. What does it do when you do this now? Will it fail and will the guest be working fine on v1 but not migrated to v2? What would my patch do concerning the migrations? Would it pass with changing NIC type to default?
Also, some bits per mips_jazz were added but usage of some constant for MIPS is not necessary since there is only one NIC model supported there. Michal Signed-off-by: Michal Novotny<address@hidden>I think adding NIC_DEFAULT_MODEL macro in net.h is problematic exactly because each platform has its own. It belongs in per-platform .c file I think.
That's right. Implementing this into the per-platform.c could be a better idea nevertheless I saw message of "Unsupported NIC" just in mips_jazz.c and net.c so maybe I got confused. The NIC_DEFAULT_MODEL definition could help to change default NIC model in the future without digging into the code so much so I was thinking it could be useful.
Michal -- Michal Novotny<address@hidden>, RHCE Virtualization Team (xen userspace), Red Hat
[Prev in Thread] | Current Thread | [Next in Thread] |