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

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

 



>>>> 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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux