Re: [PATCH v3 0/9] Generalize memory encryption models

[David Hildenbrand]

>>>> Does this have any implications when probing with the 'none' machine?
>>>
>>> I'm not sure.  In your case, I guess the cpu bit would still show up
>>> as before, so it would tell you base feature availability, but not
>>> whether you can use the new configuration option.
>>>
>>> Since the HTL option is generic, you could still set it on the "none"
>>> machine, though it wouldn't really have any effect.  That is, if you
>>> could create a suitable object to point it at, which would depend on
>>> ... details.
>>>
>>
>> The important point is that we never want the (expanded) host cpu model
>> look different when either specifying or not specifying the HTL
>> property.
> 
> Ah, yes, I see your point.  So my current suggestion will satisfy
> that, basically it is:
> 
> cpu has unpack (inc. by default) && htl specified
>       => works (allowing secure), as expected

ack

> 
> !cpu has unpack && htl specified
>       => bails out with an error

ack

> 
> !cpu has unpack && !htl specified
>       => works for a non-secure guest, as expected
>       => guest will fail if it attempts to go secure

ack, behavior just like running on older hw without unpack

> 
> cpu has unpack && !htl specified
>       => works as expected for a non-secure guest (unpack feature is
>          present, but unused)
>       => secure guest may work "by accident", but only if all virtio
>          properties have the right values, which is the user's
>          problem
> 
> That last case is kinda ugly, but I think it's tolerable.

Right, we must not affect non-secure guests, and existing secure setups
(e.g., older qemu machines). Will have to think about this some more,
but does not sound too crazy.

Thanks!

-- 
Thanks,

David / dhildenb