All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>, mdroth@linux.vnet.ibm.com
Cc: qemu-devel@nongnu.org, Drew Jones <drjones@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qga: ignore non present cpus when handling qmp_guest_get_vcpus()
Date: Thu, 6 Sep 2018 13:52:49 +0200	[thread overview]
Message-ID: <914f169f-946d-901f-008e-f426183b9119@redhat.com> (raw)
In-Reply-To: <20180906125054.764d3baa@redhat.com>

On 09/06/18 12:50, Igor Mammedov wrote:
> On Thu, 6 Sep 2018 12:26:12 +0200
> Laszlo Ersek <lersek@redhat.com> wrote:
> 
>> On 09/06/18 11:49, Igor Mammedov wrote:
>>> On Thu, 30 Aug 2018 17:51:13 +0200
>>> Laszlo Ersek <lersek@redhat.com> wrote:
>>>   
>>>> +Drew
>>>>
>>>> On 08/30/18 14:08, Igor Mammedov wrote:  
>>>>> If VM has VCPUs plugged sparselly (for example a VM started with
>>>>> 3 VCPUs (cpu0, cpu1 and cpu2) and then cpu1 was hotunplugged so
>>>>> only cpu0 and cpu2 are present), QGA will rise a error
>>>>>   error: internal error: unable to execute QEMU agent command 'guest-get-vcpus':
>>>>>   open("/sys/devices/system/cpu/cpu1/"): No such file or directory
>>>>> when
>>>>>   virsh vcpucount FOO --guest
>>>>> is executed.
>>>>> Fix it by ignoring non present CPUs when fetching CPUs status from sysfs.
>>>>>
>>>>> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
>>>>> ---
>>>>>  qga/commands-posix.c | 4 +++-
>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
>>>>> index 37e8a2d..2929872 100644
>>>>> --- a/qga/commands-posix.c
>>>>> +++ b/qga/commands-posix.c
>>>>> @@ -2044,7 +2044,9 @@ static void transfer_vcpu(GuestLogicalProcessor *vcpu, bool sys2vcpu,
>>>>>                                vcpu->logical_id);
>>>>>      dirfd = open(dirpath, O_RDONLY | O_DIRECTORY);
>>>>>      if (dirfd == -1) {
>>>>> -        error_setg_errno(errp, errno, "open(\"%s\")", dirpath);
>>>>> +        if (!(sys2vcpu && errno == ENOENT)) {
>>>>> +            error_setg_errno(errp, errno, "open(\"%s\")", dirpath);
>>>>> +        }
>>>>>      } else {
>>>>>          static const char fn[] = "online";
>>>>>          int fd;
>>>>>     
>>> [...]
>>>    
>>>> I wonder if, instead of this patch, we should rework
>>>> qmp_guest_get_vcpus(), to silently skip processors for which this
>>>> dirpath ENOENT condition arises (i.e., return a shorter list of
>>>> GuestLogicalProcessor objects).  
>>> would something like this on top of this patch do?
>>>
>>> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
>>> index 2929872..990bb80 100644
>>> --- a/qga/commands-posix.c
>>> +++ b/qga/commands-posix.c
>>> @@ -2114,12 +2114,14 @@ GuestLogicalProcessorList *qmp_guest_get_vcpus(Error **errp)
>>>          vcpu->logical_id = current++;
>>>          vcpu->has_can_offline = true; /* lolspeak ftw */
>>>          transfer_vcpu(vcpu, true, &local_err);
>>> -
>>> -        entry = g_malloc0(sizeof *entry);
>>> -        entry->value = vcpu;
>>> -
>>> -        *link = entry;
>>> -        link = &entry->next;
>>> +        if (errno == ENOENT) {
>>> +            g_free(vcpu);
>>> +        } else {
>>> +            entry = g_malloc0(sizeof *entry);
>>> +            entry->value = vcpu;
>>> +            *link = entry;
>>> +            link = &entry->next;
>>> +        }
>>>      }
>>>  
>>>      if (local_err == NULL) {
>>>
>>> [...]
>>>   
>>
>> To me that looks like the right approach, but the details should be
>> polished a bit:
>>
>> - After we drop the vcpu object, "local_err" is still set, and would
>> terminate the loop in the next iteration.
> local_error is not set due 'if (!(sys2vcpu && errno == ENOENT))'
> condition in the in the transfer_vcpu().

ah, sorry, you did say this was on top of your original patch, but I had
forgotten the details of that.

> the thing is that in case of vcpu2sys direction ENOENT is hard error.
> 
>> - It seems like ENOENT can indeed only come from openat(), in
>> transfer_vcpu(), however, it would be nice if we could grab the error
>> code from the error object somehow, and not from the "errno" variable. I
>> vaguely recall this is what error classes were originally invented for,
>> but now we just use ERROR_CLASS_GENERIC_ERROR...
> I've checked it and errno is preserved during error_setg_errno() call but
> not saved in Error, so I've dropped that idea.
>  
>> How about this: we could add a boolean output param to transfer_vcpu(),
>> called "fatal". Ignored when the function succeeds. When the function
>> fails (seen from "local_err"), the loop consults "fatal". If the error
>> is fatal, we act as before; otherwise, we drop the vcpu object, release
>> -- and zero out -- "local_err" as well, and continue. I think this is
>> more generic / safer than trying to infer the failure location from the
>> outside.
> It looked more uglier to me, so I've turned to libc style of reporting
> (assuming that g_free() doesn't touch errno ever)
> 
> But if you prefer using extra parameter, I'll respin patch with it.

Michael, what is your preference? I guess I'll be fine both ways.

Thanks,
Laszlo

> 
>> I'm not quite up to date on structured error propagation in QEMU, so
>> take the above with a grain of salt...
>>
>> Thanks,
>> Laszlo
> 

  reply	other threads:[~2018-09-06 11:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 12:08 [Qemu-devel] [PATCH] qga: ignore non present cpus when handling qmp_guest_get_vcpus() Igor Mammedov
2018-08-30 15:51 ` Laszlo Ersek
2018-08-31  8:00   ` Igor Mammedov
2018-08-31 10:19     ` Laszlo Ersek
2018-09-06  9:00       ` [Qemu-devel] [libvirt] " Peter Krempa
2018-08-31 11:22   ` [Qemu-devel] " Andrew Jones
2018-09-05  0:12     ` Michael Roth
2018-09-06  9:49   ` Igor Mammedov
2018-09-06 10:26     ` Laszlo Ersek
2018-09-06 10:50       ` Igor Mammedov
2018-09-06 11:52         ` Laszlo Ersek [this message]
2018-09-06 12:00           ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=914f169f-946d-901f-008e-f426183b9119@redhat.com \
    --to=lersek@redhat.com \
    --cc=drjones@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.