Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-07-21 Thread Kamil Rytarowski
On 10.03.2020 07:45, Maxime Villard wrote: > Le 02/03/2020 à 20:35, Paolo Bonzini a écrit : >> >> >> Il lun 2 mar 2020, 20:28 Maxime Villard > > ha scritto: >> >> >> >> +        nvmm_vcpu_pre_run(cpu); >> >> + >> >> +        if (atomic_read(>exit_request)) { >>

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-12 Thread Maxime Villard
Le 11/03/2020 à 22:44, Paolo Bonzini a écrit : > On 11/03/20 22:21, Maxime Villard wrote: >>> Yes, you don't know how long that run would take. I don't know about >>> NVMM but for KVM it may even never leave if the guest is in HLT state. >> Ok, I see, thanks. >> >> In NVMM the runs are short > >

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-11 Thread Paolo Bonzini
On 11/03/20 22:21, Maxime Villard wrote: >> Yes, you don't know how long that run would take. I don't know about >> NVMM but for KVM it may even never leave if the guest is in HLT state. > Ok, I see, thanks. > > In NVMM the runs are short How do you ensure that a guest with interrupts off exits

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-11 Thread Kamil Rytarowski
On 11.03.2020 22:21, Maxime Villard wrote: > Le 11/03/2020 à 21:42, Paolo Bonzini a écrit : >> On 11/03/20 21:14, Maxime Villard wrote: The problem is that qcpu->stop is checked _before_ entering the hypervisor and not after, so there is a small race window. >>> Ok. I don't understand

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-11 Thread Maxime Villard
Le 11/03/2020 à 21:42, Paolo Bonzini a écrit : > On 11/03/20 21:14, Maxime Villard wrote: >>> The problem is that qcpu->stop is checked _before_ entering the >>> hypervisor and not after, so there is a small race window. >> Ok. I don't understand what's supposed to be the race here. If we get an

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-11 Thread Paolo Bonzini
On 11/03/20 21:14, Maxime Villard wrote: >> The problem is that qcpu->stop is checked _before_ entering the >> hypervisor and not after, so there is a small race window. > Ok. I don't understand what's supposed to be the race here. If we get an > IPI between the check and the call to

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-11 Thread Maxime Villard
Le 11/03/2020 à 19:03, Paolo Bonzini a écrit : > On 10/03/20 20:14, Maxime Villard wrote: >> Maybe, whpx_vcpu_kick() causes a WHvRunVpExitReasonCanceled in the >> WHvRunVirtualProcessor() call that follows, which in turn causes "ret=1" >> to leave the loop. That is, maybe the next

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-11 Thread Paolo Bonzini
On 10/03/20 20:14, Maxime Villard wrote: > Maybe, whpx_vcpu_kick() causes a WHvRunVpExitReasonCanceled in the > WHvRunVirtualProcessor() call that follows, which in turn causes "ret=1" > to leave the loop. That is, maybe the next WHvRunVirtualProcessor() acks > the cancellation and leaves without

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-10 Thread Maxime Villard
Le 10/03/2020 à 11:58, Paolo Bonzini a écrit : > On 10/03/20 07:45, Maxime Villard wrote: >>> It reproduces the existing logic found in whpx-all.c, and if there is >>> >> >> It's buggy there too and it has to be fixed in the hypervisor so it >> can't be done at the same time I'm both. KVM does it

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-10 Thread Paolo Bonzini
On 10/03/20 07:45, Maxime Villard wrote: > > It reproduces the existing logic found in whpx-all.c, and if there is > > > > It's buggy there too and it has to be fixed in the hypervisor so it > can't be done at the same time I'm both. KVM does it right by having > a flag ("immediate_exit") that is

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-10 Thread Kamil Rytarowski
On 10.03.2020 07:45, Maxime Villard wrote: > Le 02/03/2020 à 20:35, Paolo Bonzini a écrit : >> >> >> Il lun 2 mar 2020, 20:28 Maxime Villard > > ha scritto: >> >> >> >> +        nvmm_vcpu_pre_run(cpu); >> >> + >> >> +        if (atomic_read(>exit_request)) { >>

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-10 Thread Maxime Villard
Le 02/03/2020 à 20:35, Paolo Bonzini a écrit : > > > Il lun 2 mar 2020, 20:28 Maxime Villard > ha scritto: > > > >> +        nvmm_vcpu_pre_run(cpu); > >> + > >> +        if (atomic_read(>exit_request)) { > >> +            qemu_cpu_kick_self(); > >>

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-02 Thread Paolo Bonzini
Il lun 2 mar 2020, 20:28 Maxime Villard ha scritto: > > >> +nvmm_vcpu_pre_run(cpu); > >> + > >> +if (atomic_read(>exit_request)) { > >> +qemu_cpu_kick_self(); > >> +} > >> + > > > > This is racy without something like KVM's immediate_exit mechanism. > > This

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-02 Thread Maxime Villard
Le 02/03/2020 à 19:13, Paolo Bonzini a écrit : > On 06/02/20 22:32, Kamil Rytarowski wrote: >> +get_qemu_vcpu(CPUState *cpu) >> +{ >> +return (struct qemu_vcpu *)cpu->hax_vcpu; >> +} > > Please make hax_vcpu a void * and rename it to "accel_data". NVMM reproduces the existing logic in the

Re: [PATCH v4 3/4] Introduce the NVMM impl

2020-03-02 Thread Paolo Bonzini
On 06/02/20 22:32, Kamil Rytarowski wrote: > +get_qemu_vcpu(CPUState *cpu) > +{ > +return (struct qemu_vcpu *)cpu->hax_vcpu; > +} Please make hax_vcpu a void * and rename it to "accel_data". > +nseg->attrib.g = __SHIFTOUT(attrib, DESC_G_MASK); > +

[PATCH v4 3/4] Introduce the NVMM impl

2020-02-06 Thread Kamil Rytarowski
From: Maxime Villard Implements the NetBSD Virtual Machine Monitor (NVMM) target. Which acts as a hypervisor accelerator for QEMU on the NetBSD platform. This enables QEMU much greater speed over the emulated x86_64 path's that are taken on NetBSD today. Signed-off-by: Maxime Villard