Fabiano Rosas <faro...@suse.de> writes:
> Vikram Garhwal <vikram.garh...@amd.com> writes:
>
>> Add CONFIG_XEN for aarch64 device to support build for ARM targets.
>>
>> Signed-off-by: Vikram Garhwal <vikram.garh...@amd.com>
>> Signed-off-by: Stefano Stabellini <stefano.stabell...@amd.com>
>> Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
>> ---
>> meson.build | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meson.build b/meson.build
>> index 52c3995c9d..eb5bb305ae 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -135,7 +135,7 @@ endif
>> if cpu in ['x86', 'x86_64', 'arm', 'aarch64']
>> # i386 emulator provides xenpv machine type for multiple architectures
>> accelerator_targets += {
>> - 'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu'],
>> + 'CONFIG_XEN': ['i386-softmmu', 'x86_64-softmmu',
>> 'aarch64-softmmu'],
>
> I'm not familiar with Xen, so pardon my ignorance, but would it (ever)
> make sense to do a 1:1 map of host architecture and qemu target? So we
> don't have to deal with having a build on x86 pulling aarch64-softmmu
> and vice-versa.
>
> Do we expect both x86_64-softmmu and aarch64-softmmu binaries to be used
> in the same host?
Xen is different from the other accelerators as it isn't really guest
CPU aware. It is merely io device emulation backend albeit one that
supports a non-paravirtualised guest on x86. But you are right that
using qemu-system-i386 as a backend on aarch64 hosts does cause some
cognitive dissonance for users. For aarch64 hosts we would only support
the VirtIO guests.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
