| Message ID | 20200322210211.29603-1-vr_qemu@t-online.de |
|---|---|
| State | New |
| Headers | show |
| Series | hax: Windows doesn't like posix device names | expand |
On 22/03/20 22:02, Volker Rümelin wrote: > Patch acb9f95a7c "i386: Fix GCC warning with snprintf when HAX > is enabled" replaced Windows device names with posix device > names. Revert this. > > Fixes: acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled" > > Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> > --- > target/i386/hax-windows.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/target/i386/hax-windows.c b/target/i386/hax-windows.c > index 0ba488c468..863c2bcc19 100644 > --- a/target/i386/hax-windows.c > +++ b/target/i386/hax-windows.c > @@ -185,12 +185,12 @@ int hax_mod_version(struct hax_state *hax, struct hax_module_version *version) > > static char *hax_vm_devfs_string(int vm_id) > { > - return g_strdup_printf("/dev/hax_vm/vm%02d", vm_id); > + return g_strdup_printf("\\\\.\\hax_vm%02d", vm_id); > } > > static char *hax_vcpu_devfs_string(int vm_id, int vcpu_id) > { > - return g_strdup_printf("/dev/hax_vm%02d/vcpu%02d", vm_id, vcpu_id); > + return g_strdup_printf("\\\\.\\hax_vm%02d_vcpu%02d", vm_id, vcpu_id); > } > > int hax_host_create_vm(struct hax_state *hax, int *vmid) > Queued, thanks. Paolo
Am 23.03.20 um 09:20 schrieb Paolo Bonzini: > On 22/03/20 22:02, Volker Rümelin wrote: >> Patch acb9f95a7c "i386: Fix GCC warning with snprintf when HAX >> is enabled" replaced Windows device names with posix device >> names. Revert this. >> >> Fixes: acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled" >> >> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> >> --- >> target/i386/hax-windows.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/target/i386/hax-windows.c b/target/i386/hax-windows.c >> index 0ba488c468..863c2bcc19 100644 >> --- a/target/i386/hax-windows.c >> +++ b/target/i386/hax-windows.c >> @@ -185,12 +185,12 @@ int hax_mod_version(struct hax_state *hax, struct hax_module_version *version) >> >> static char *hax_vm_devfs_string(int vm_id) >> { >> - return g_strdup_printf("/dev/hax_vm/vm%02d", vm_id); >> + return g_strdup_printf("\\\\.\\hax_vm%02d", vm_id); >> } >> >> static char *hax_vcpu_devfs_string(int vm_id, int vcpu_id) >> { >> - return g_strdup_printf("/dev/hax_vm%02d/vcpu%02d", vm_id, vcpu_id); >> + return g_strdup_printf("\\\\.\\hax_vm%02d_vcpu%02d", vm_id, vcpu_id); >> } >> >> int hax_host_create_vm(struct hax_state *hax, int *vmid) >> > Queued, thanks. > > Paolo I am rather sure that macOS does not like Windows device names, so just reverting might be the wrong solution if HAX should work on Windows and on macOS. Is this relevant? Or should we drop HAX support for Windows? Personally I have no experience with hardware acceleration for QEMU on macOS. Stefan
On 09/04/20 15:24, Stefan Weil wrote: >>> diff --git a/target/i386/hax-windows.c b/target/i386/hax-windows.c >>> index 0ba488c468..863c2bcc19 100644 >>> --- a/target/i386/hax-windows.c >>> +++ b/target/i386/hax-windows.c >>> @@ -185,12 +185,12 @@ int hax_mod_version(struct hax_state *hax, struct hax_module_version *version) >>> >>> static char *hax_vm_devfs_string(int vm_id) >>> { >>> - return g_strdup_printf("/dev/hax_vm/vm%02d", vm_id); >>> + return g_strdup_printf("\\\\.\\hax_vm%02d", vm_id); >>> } >>> >>> static char *hax_vcpu_devfs_string(int vm_id, int vcpu_id) >>> { >>> - return g_strdup_printf("/dev/hax_vm%02d/vcpu%02d", vm_id, vcpu_id); >>> + return g_strdup_printf("\\\\.\\hax_vm%02d_vcpu%02d", vm_id, vcpu_id); >>> } >>> >>> int hax_host_create_vm(struct hax_state *hax, int *vmid) >>> >> Queued, thanks. >> >> Paolo > > I am rather sure that macOS does not like Windows device names, so just > reverting might be the wrong solution if HAX should work on Windows and > on macOS. This is hax-windows.c, macOS uses hax-posix.c. These days Hypervisor.framework is probably a better choice than HAX on macOS, but IIUC hax-posix.c also supports NetBSD so we're keeping it. Paolo > Is this relevant? Or should we drop HAX support for Windows? Personally > I have no experience with hardware acceleration for QEMU on macOS.
> Is this relevant? Or should we drop HAX support for Windows? Personally > I have no experience with hardware acceleration for QEMU on macOS. There's another reason to keep hax for Windows. You can't enable the Hyper-V role on Windows 10 Home. Without hax and whpx there's no usable hypervisor left. With best regards, Volker > Stefan > > >
> On 22/03/20 22:02, Volker Rümelin wrote: >> Patch acb9f95a7c "i386: Fix GCC warning with snprintf when HAX >> is enabled" replaced Windows device names with posix device >> names. Revert this. >> >> Fixes: acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled" >> Queued, thanks. >> >> Paolo >> Hi Paolo, I would like to remind you that without this patch qemu 5.0 on Windows will not work with HAX. There is already a bug report at https://bugs.launchpad.net/bugs/1871250 With best regards, Volker
diff --git a/target/i386/hax-windows.c b/target/i386/hax-windows.c index 0ba488c468..863c2bcc19 100644 --- a/target/i386/hax-windows.c +++ b/target/i386/hax-windows.c @@ -185,12 +185,12 @@ int hax_mod_version(struct hax_state *hax, struct hax_module_version *version) static char *hax_vm_devfs_string(int vm_id) { - return g_strdup_printf("/dev/hax_vm/vm%02d", vm_id); + return g_strdup_printf("\\\\.\\hax_vm%02d", vm_id); } static char *hax_vcpu_devfs_string(int vm_id, int vcpu_id) { - return g_strdup_printf("/dev/hax_vm%02d/vcpu%02d", vm_id, vcpu_id); + return g_strdup_printf("\\\\.\\hax_vm%02d_vcpu%02d", vm_id, vcpu_id); } int hax_host_create_vm(struct hax_state *hax, int *vmid)
Patch acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled" replaced Windows device names with posix device names. Revert this. Fixes: acb9f95a7c "i386: Fix GCC warning with snprintf when HAX is enabled" Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> --- target/i386/hax-windows.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)