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