Thanks for the reply. On 4/7/20 9:28 AM, Daniel P. Berrangé wrote: > On Tue, Apr 07, 2020 at 08:01:50AM -0400, Liang Yan wrote: >> Thanks for the input. >> >> On 4/7/20 3:54 AM, Andrea Bolognani wrote: >>> On Mon, 2020-04-06 at 16:51 -0400, Liang Yan wrote: >>>> virt-install already uses 'host-passthrough' as default when no setup >>>> for cmline '--cpu'. However, it will still use 'host-model' when comes >>>> with '-cpu host'. This will be a problem for aarch64 platfrom as >>>> 'host-model' for aarch64 kvm domain on aarch64 host is not supported yet. >>> >>> virt-install's --cpu host maps to libvirt's >>> >>> <cpu mode='host-model'/> >>> >>> while virt-install's --cpu host-passthrough maps to libvirt's >>> >>> <cpu mode='host-passthrough'/> >>> >>> These semantics are not architecture dependent and, while the choice >>> of name is a bit unfortunate considering that QEMU's -cpu host and >>> virt-install's --cpu host have different meanings, I think they're >>> completely unambiguous and reasonably documented, and we should not >>> mess with them. >>> >> >> >> virt-install supports both "host","host-mdoel" and "host-passthrough", >> "--cpu host" is mapped to "host-model" based on "cli:det_model_b", >> however if you check the default setup in "cpu"set_defaults", it has >> different configuration. Btw, it has different setup for different >> architecture already. Nova also has different setup for aarch64 in my >> defense. >> >> https://opendev.org/openstack/nova/commit/8bc7b950b7c0a3c80cdd120fe4df97c14848c344 >> >> >> >> I agree we could document this situation at least. It does block our >> aarch64 tests while it is ok for x86_64. > > That is a bug in the tests - they shouldn't be trying to use a feature > which doesn't make sense for that arch, > If "--cpu host" means "--cpu host-model" and we could setup "--cpu host-model" manually and there is situation could not support "--cpu host", maybe we just use "--cpu host-model" instead? Just personally thought "host" "host-model" and "host-passthrough" are a little bit confusion here. We may improve the error message with more hints at least. Best, Liang > > Regards, > Daniel >
