qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1
Date: Wed, 09 Mar 2011 08:15:02 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/09/2011 07:55 AM, Avi Kivity wrote:
On 03/09/2011 03:51 PM, Anthony Liguori wrote:
{ execute: 'write-keystore' arguments: { 'key': 'foo', 'value': 'bar' } }

This is coming from the guest?

Yes.


So what about:

{ 'KeyStore': { '*foo': 'str', '*otherkey': 'str' } }
[ 'guest-write-keystore', { 'keystore': 'KeyStore' }, 'none' ]

{ 'GUEST_UPDATE_KEYSTORE': { 'keys': [ 'str' ] } }

(why the CAPS?)

Sad to say, but legacy.  That's how we do events today.


In this model, the key store is actually stored in the guest. If the guest wants the latest version of a value, it sends an event to get keys updated. The host can update keys at any point in time.

This survives live migration, but not guest reboots or crashes.

Right, management tool (or QEMU) needs to keep a copy if it's to survive reset.

But since we don't have a concrete use-case, I'm really just trying to show that we don't need bidirectional RPC for these types of things.

Regards,

Anthony Liguori




reply via email to

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