qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V2 3/3] virtio-net: announce self by guest


From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH V2 3/3] virtio-net: announce self by guest
Date: Wed, 11 Jun 2014 10:50:04 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 06/10/2014 06:10 PM, Michael S. Tsirkin wrote:
> On Tue, Jun 10, 2014 at 11:50:33AM +0530, Amit Shah wrote:
>> On (Tue) 20 May 2014 [14:01:44], Jason Wang wrote:
>>> It's hard to track all mac addresses and their configurations (e.g
>>> vlan or ipv6) in qemu. Without this information, it's impossible to
>>> build proper garp packet after migration. The only possible solution
>>> to this is let guest (who knows all configurations) to do this.
>>>
>>> So, this patch introduces a new readonly config status bit of virtio-net,
>>> VIRTIO_NET_S_ANNOUNCE which is used to notify guest to announce
>>> presence of its link through config update interrupt.When guest has
>>> done the announcement, it should ack the notification through
>>> VIRTIO_NET_CTRL_ANNOUNCE_ACK cmd. This feature is negotiated by a new
>>> feature bit VIRTIO_NET_F_ANNOUNCE (which has already been supported by
>>> Linux guest).
>>>
>>> During load, a counter of announcing rounds is set so that after the vm is
>>> running it can trigger rounds of config interrupts to notify the guest to 
>>> build
>>> and send the correct garps.
>> Live migration is supposed to be transparent to guests.
>>
>> Doing things this way makes the guest involved in live migration.
>> It's not desirable.
> I'm not sure there's a problem.
> As long as guest doesn't use networking, it does not
> need to be involved. If guest does want to use networking,
> it needs to be involved, but then it's accessing the
> device anyway.
>
>> For networking, this may well be not possible.
>> Are there any ways of doing this w/o involving the guest that have
>> been considered?
>>
>>
>>              Amit
> Since we don't know guest addresses, this looks like the only way to me.
>

Yes and this method were also used by Xen and HyperV.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]