On 3/3/23 18:39, Haitao Shan wrote:
No, we're always open to new proposals. It merely means that it
might be harder to justify why the new hypervisor is a net benefit
for QEMU, when there is a competing solution supported by the OS
vendor.
Thanks for the clarification. It is great that the door is not shut completely.
Hi,
sorry for not answering before.
I think in general QEMU should be open to merging work from the Android
Emulator. If AEHD is useful to the Android emulator, I would consider
it interesting for QEMU as well.
However, I would rather have it as an extension to KVM if possible
rather than a completely new emulator. One possibility is to introduce
a new file that encapsulates all KVM ioctls, with a struct that
encapsulates the Unix file descriptor/Windows HANDLE. For example
int kvm_ioctl_get_supported_cpuid(KVMState *s, struct kvm_cpuid *cpuid,
int max)
{
cpuid->nent = max;
#ifdef CONFIG_POSIX
return ioctl(s, KVM_GET_SUPPORTED_VCPUID, cpuid);
#else
size_t size = sizeof(*cpuid) + max * sizeof(*cpuid->entries);
return aehd_ioctl(s, AEHD_GET_SUPPORTED_CPUID, cpuid, size, cpuid,
size);
#endif
}
int kvm_ioctl_create_vcpu(KVMState *s, int vcpu_id, CPUState *out)
{
#ifdef CONFIG_POSIX
out.kvm_fd = kvm_vm_ioctl(KVM_CREATE_VCPU, vcpu_id);
return out.kvm_fd;
#else
return aehd_vm_ioctl(s, AEHD_CREATE_VCPU, &vcpu_id, sizeof(vcpu_id),
&out.kvm_fd, sizeof(out.kvm_fd));
#endif
}
etc.
These are just general examples, the actual level of abstraction is up
to you.
Paolo
