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

[Janosch Frank <frankja@linux.ibm.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2695 bytes --]

On 6/26/20 8:53 AM, David Hildenbrand wrote:
>>>>> 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.

I severely dislike having to specify things to make PV work.
The IOMMU is already a thorn in our side and we're working on making the
whole ordeal completely transparent so the only requirement to make this
work is the right machine, kernel, qemu and kernel cmd line option
"prot_virt=1". That's why we do the reboot into PV mode in the first place.

I.e. the goal is that if customers convert compatible guests into
protected ones and start them up on a z15 on a distro with PV support
they can just use the guest without having to change XML or command line
parameters.

Internal customers have already created bugs because they did not follow
the documentation and the more cmd options we bring the more bugzillas
we'll get.

PV is already in the field/GA and can be ordered, as is our documentation.

@Christian: Please chime in here

> 
> Thanks!
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]