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
