After digging through the source code, I found event_notifier_cleanup() only
closes the eventfd, but does not de-register the event from QEMU’s event
loop. event_notifier_set_handler() actually interacts with the event loop.
It is a wrapper around aio_set_event_notifier(), which is again a wrapper
On Jul 27 16:16, Jinhao Fan wrote:
> at 3:06 PM, Klaus Jensen wrote:
>
> > On Jul 26 14:08, Klaus Jensen wrote:
> >> Alright. Forget about the iommu, that was just a coincidence.
> >>
> >> This patch seems to fix it. I guess it is the
> >> event_notifier_set_handler(..., NULL) that does the
at 3:06 PM, Klaus Jensen wrote:
> On Jul 26 14:08, Klaus Jensen wrote:
>> Alright. Forget about the iommu, that was just a coincidence.
>>
>> This patch seems to fix it. I guess it is the
>> event_notifier_set_handler(..., NULL) that does the trick, but I'd like
>> to understand why ;)
>>
>>
On Jul 26 14:08, Klaus Jensen wrote:
>
> Alright. Forget about the iommu, that was just a coincidence.
>
> This patch seems to fix it. I guess it is the
> event_notifier_set_handler(..., NULL) that does the trick, but I'd like
> to understand why ;)
>
>
> diff --git i/hw/nvme/ctrl.c
On Tue, 5 Jul 2022 at 10:25, Jinhao Fan wrote:
>
> Add property "ioeventfd" which is enabled by default. When this is
> enabled, updates on the doorbell registers will cause KVM to signal
> an event to the QEMU main loop to handle the doorbell updates.
> Therefore, instead of letting the vcpu
On Jul 26 13:32, Klaus Jensen wrote:
> On Jul 26 13:24, Klaus Jensen wrote:
> > On Jul 26 12:09, Klaus Jensen wrote:
> > > On Jul 26 11:19, Klaus Jensen wrote:
> > > > On Jul 26 15:55, Jinhao Fan wrote:
> > > > > at 3:41 PM, Klaus Jensen wrote:
> > > > >
> > > > > > On Jul 26 15:35, Jinhao Fan
On Jul 26 13:24, Klaus Jensen wrote:
> On Jul 26 12:09, Klaus Jensen wrote:
> > On Jul 26 11:19, Klaus Jensen wrote:
> > > On Jul 26 15:55, Jinhao Fan wrote:
> > > > at 3:41 PM, Klaus Jensen wrote:
> > > >
> > > > > On Jul 26 15:35, Jinhao Fan wrote:
> > > > >> at 4:55 AM, Klaus Jensen wrote:
>
On Jul 26 12:09, Klaus Jensen wrote:
> On Jul 26 11:19, Klaus Jensen wrote:
> > On Jul 26 15:55, Jinhao Fan wrote:
> > > at 3:41 PM, Klaus Jensen wrote:
> > >
> > > > On Jul 26 15:35, Jinhao Fan wrote:
> > > >> at 4:55 AM, Klaus Jensen wrote:
> > > >>
> > > >>> We have a regression following
On Jul 26 11:19, Klaus Jensen wrote:
> On Jul 26 15:55, Jinhao Fan wrote:
> > at 3:41 PM, Klaus Jensen wrote:
> >
> > > On Jul 26 15:35, Jinhao Fan wrote:
> > >> at 4:55 AM, Klaus Jensen wrote:
> > >>
> > >>> We have a regression following this patch that we need to address.
> > >>>
> > >>>
On Jul 26 15:55, Jinhao Fan wrote:
> at 3:41 PM, Klaus Jensen wrote:
>
> > On Jul 26 15:35, Jinhao Fan wrote:
> >> at 4:55 AM, Klaus Jensen wrote:
> >>
> >>> We have a regression following this patch that we need to address.
> >>>
> >>> With this patch, issuing a reset on the device (`nvme
at 3:41 PM, Klaus Jensen wrote:
> On Jul 26 15:35, Jinhao Fan wrote:
>> at 4:55 AM, Klaus Jensen wrote:
>>
>>> We have a regression following this patch that we need to address.
>>>
>>> With this patch, issuing a reset on the device (`nvme reset /dev/nvme0`
>>> will do the trick) causes QEMU
On Jul 26 15:35, Jinhao Fan wrote:
> at 4:55 AM, Klaus Jensen wrote:
>
> >
> > We have a regression following this patch that we need to address.
> >
> > With this patch, issuing a reset on the device (`nvme reset /dev/nvme0`
> > will do the trick) causes QEMU to hog my host cpu at 100%.
> >
at 4:55 AM, Klaus Jensen wrote:
>
> We have a regression following this patch that we need to address.
>
> With this patch, issuing a reset on the device (`nvme reset /dev/nvme0`
> will do the trick) causes QEMU to hog my host cpu at 100%.
>
> I'm still not sure what causes this. The trace
On Jul 5 22:24, Jinhao Fan wrote:
> Add property "ioeventfd" which is enabled by default. When this is
> enabled, updates on the doorbell registers will cause KVM to signal
> an event to the QEMU main loop to handle the doorbell updates.
> Therefore, instead of letting the vcpu thread run both
On Jul 12 14:23, Klaus Jensen wrote:
> On Jul 9 11:06, Jinhao Fan wrote:
> > at 10:24 PM, Jinhao Fan wrote:
> >
> > > @@ -5793,6 +5891,7 @@ static uint16_t nvme_dbbuf_config(NvmeCtrl *n,
> > > const NvmeRequest *req)
> > > uint64_t dbs_addr = le64_to_cpu(req->cmd.dptr.prp1);
> > >
On Jul 9 11:06, Jinhao Fan wrote:
> at 10:24 PM, Jinhao Fan wrote:
>
> > @@ -5793,6 +5891,7 @@ static uint16_t nvme_dbbuf_config(NvmeCtrl *n, const
> > NvmeRequest *req)
> > uint64_t dbs_addr = le64_to_cpu(req->cmd.dptr.prp1);
> > uint64_t eis_addr = le64_to_cpu(req->cmd.dptr.prp2);
>
at 10:24 PM, Jinhao Fan wrote:
> @@ -5793,6 +5891,7 @@ static uint16_t nvme_dbbuf_config(NvmeCtrl *n, const
> NvmeRequest *req)
> uint64_t dbs_addr = le64_to_cpu(req->cmd.dptr.prp1);
> uint64_t eis_addr = le64_to_cpu(req->cmd.dptr.prp2);
> int i;
> +int ret;
>
I just noticed
at 1:51 PM, Klaus Jensen wrote:
> On Jul 6 19:34, Jinhao Fan wrote:
>> at 2:43 AM, Keith Busch wrote:
>>
>>> On Tue, Jul 05, 2022 at 07:11:36PM +0200, Klaus Jensen wrote:
On Jul 5 22:24, Jinhao Fan wrote:
> @@ -1374,7 +1374,14 @@ static void nvme_enqueue_req_completion(NvmeCQueue
On Jul 6 19:34, Jinhao Fan wrote:
> at 2:43 AM, Keith Busch wrote:
>
> > On Tue, Jul 05, 2022 at 07:11:36PM +0200, Klaus Jensen wrote:
> >> On Jul 5 22:24, Jinhao Fan wrote:
> >>> @@ -1374,7 +1374,14 @@ static void nvme_enqueue_req_completion(NvmeCQueue
> >>> *cq, NvmeRequest *req)
> >>>
>
at 2:43 AM, Keith Busch wrote:
> On Tue, Jul 05, 2022 at 07:11:36PM +0200, Klaus Jensen wrote:
>> On Jul 5 22:24, Jinhao Fan wrote:
>>> @@ -1374,7 +1374,14 @@ static void nvme_enqueue_req_completion(NvmeCQueue
>>> *cq, NvmeRequest *req)
>>>
>>> QTAILQ_REMOVE(>sq->out_req_list, req,
at 1:11 AM, Klaus Jensen wrote:
> On Jul 5 22:24, Jinhao Fan wrote:
>> Add property "ioeventfd" which is enabled by default. When this is
>> enabled, updates on the doorbell registers will cause KVM to signal
>> an event to the QEMU main loop to handle the doorbell updates.
>> Therefore,
On Tue, Jul 05, 2022 at 07:11:36PM +0200, Klaus Jensen wrote:
> On Jul 5 22:24, Jinhao Fan wrote:
> > @@ -1374,7 +1374,14 @@ static void nvme_enqueue_req_completion(NvmeCQueue
> > *cq, NvmeRequest *req)
> >
> > QTAILQ_REMOVE(>sq->out_req_list, req, entry);
> >
On Jul 5 22:24, Jinhao Fan wrote:
> Add property "ioeventfd" which is enabled by default. When this is
> enabled, updates on the doorbell registers will cause KVM to signal
> an event to the QEMU main loop to handle the doorbell updates.
> Therefore, instead of letting the vcpu thread run both
Add property "ioeventfd" which is enabled by default. When this is
enabled, updates on the doorbell registers will cause KVM to signal
an event to the QEMU main loop to handle the doorbell updates.
Therefore, instead of letting the vcpu thread run both guest VM and
IO emulation, we now use the
24 matches
Mail list logo
