All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Alon Levy <alevy@redhat.com>
Cc: qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/2] USB CCID device
Date: Thu, 07 Oct 2010 14:54:46 -0500	[thread overview]
Message-ID: <4CAE2586.1080003@codemonkey.ws> (raw)
In-Reply-To: <2052681331.708791286437179606.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>

On 10/07/2010 02:39 AM, Alon Levy wrote:
> ----- "Anthony Liguori"<anthony@codemonkey.ws>  wrote:
>
>    
>> On 10/06/2010 03:55 AM, Gerd Hoffmann wrote:
>>      
>>> On 10/06/10 02:28, Alon Levy wrote:
>>>        
>>>>          
>>>>> Does this work with live migration?  I can't see how it would.
>>>>>
>>>>>            
>>>> No, it doesn't right now. It would require cooperation with the
>>>>          
>> client,
>>      
>>>> to tell it to reconnect to the target qemu (kind of like spice).
>>>>          
>>> I think until we have this migration should have pretty much the
>>>        
>> same
>>      
>>> effect as a chardev disconnect, i.e. detach the usb device (which
>>>        
>> the
>>      
>>> guest will see as unplug).
>>>        
>> Better yet, mark the guest as unmigrateable and let the management
>> tool
>> unplug the usb device before migration and replug it after migration.
>>
>> It's the same principle behind device assignment.
>>
>>      
> Is there any way to also get a pre_migrate callback with register_device_unmigratable?
> I'd like to send a VSC_Reconnect message, then the guest sees an unplug, then migration,
>    

No.  The disconnect needs to happen in the management tooling layer.   
Same is true for any device doing hardware passthrough.

Automagic unplugging/plugging during migration is not a good idea 
universally so it's something that needs to happen as a policy at the 
management level.

Regards,

Anthony Liguori

> then (no plug yet since the device is marked as auto_attach=0) client reconnects
> (actually this happens before but to a paused machine waiting for migration), and then
> causes attachement, same as a new machine.
>
>    
>> Regards,
>>
>> Anthony Liguori
>>
>>      
>>> Needs some code though, at minimum you'll have to xfer the connected
>>>        
>>      
>>> state from the migration source and have some bits in post_load()
>>> which do attach/detach if needed.
>>>
>>> cheers,
>>>    Gerd
>>>
>>>        

  reply	other threads:[~2010-10-07 19:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1820922650.529041286324880996.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-10-06  0:28 ` [Qemu-devel] [PATCH 0/2] USB CCID device Alon Levy
2010-10-06  8:55   ` Gerd Hoffmann
2010-10-06 19:00     ` Anthony Liguori
2010-10-07  7:14       ` Gerd Hoffmann
2010-10-07  7:39       ` Alon Levy
2010-10-07 19:54         ` Anthony Liguori [this message]
2010-10-06 19:02   ` Anthony Liguori
2010-10-06 22:12     ` Alon Levy
2010-10-07 19:56       ` Anthony Liguori
     [not found] <668252848.649521286402747765.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2010-10-06 22:06 ` Alon Levy
2010-10-05 21:32 Alon Levy
2010-10-05 23:02 ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CAE2586.1080003@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=alevy@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.