From mboxrd@z Thu Jan  1 00:00:00 1970
From: Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [RFC] kvm: x86: export vCPU halted state to sysfs
Date: Fri, 2 Feb 2018 13:50:33 -0500
Message-ID: <20180202135033.3ecfdd7b@redhat.com>
References: <20180201201514.GB660@flask>
        <20180201202649.GG26425@localhost.localdomain>
        <edc27e9a-9660-eed0-dd03-016fa2e966b7@linux.vnet.ibm.com>
        <20180202141554.GH26425@localhost.localdomain>
        <96d66ae2-5c51-510f-06a5-cecdda74cfd4@linux.vnet.ibm.com>
        <20180202102231.7dc9a945@redhat.com>
        <86571633-ae6d-5678-7611-549ff41dccd8@linux.vnet.ibm.com>
        <20180202155415.GN15403@redhat.com>
        <20180202110137.2e2c1816@redhat.com>
        <597d7701-ea7b-524e-7632-10073284d060@linux.vnet.ibm.com>
        <20180202174249.GA22556@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>,
        "Daniel P. =?UTF-8?B?QmVycmFuZ8Op?=" <berrange@redhat.com>,
        Radim =?UTF-8?B?S3LEjW0=?= =?UTF-8?B?w6HFmQ==?=
        <rkrcmar@redhat.com>, kvm@vger.kernel.org, pbonzini@redhat.com,
        Peter Krempa <pkrempa@redhat.com>,
        John Ferlan <jferlan@redhat.com>, libvir-list@redhat.com,
        Christian Borntraeger <borntraeger@de.ibm.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:39032 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752421AbeBBSui (ORCPT <rfc822;kvm@vger.kernel.org>);
        Fri, 2 Feb 2018 13:50:38 -0500
In-Reply-To: <20180202174249.GA22556@localhost.localdomain>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, 2 Feb 2018 15:42:49 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Fri, Feb 02, 2018 at 05:19:34PM +0100, Viktor Mihajlovski wrote:
> > On 02.02.2018 17:01, Luiz Capitulino wrote:  
> [...]
> > >  o Make qemuDomainRefreshVcpuHalted() s390-only in libvirt. This by
> > >    itself fixes the original performance issue  
> > We are normally trying to avoid architecture-specific code in libvirt
> > (not always successfully). We could omit the call, based on a QEMU
> > Capability derived from the presence of said flag. This would change the
> > libvirt-client side default to not report halted. A client can the still
> > request the value via a tbd libvirt flag. Which is what an s390-aware
> > management app would have to do...  
> 
> The problem I see here is that the current semantics of the
> "halted" field in QEMU is arch-specific, so either libvirt or
> upper layers will necessarily need arch-specific code if they
> want to support QEMU 2.11 or older.

My understanding of this plan is:

1. Deprecate the "halted" field in query-cpus (that is, make it
   always return halted=false)

2. Add a new command, say query-cpu-state, which is arch dependent
   and is only available in archs that support sane "halted"
   semantics (I guess we can have per-arch QMP commands, right?)

3. Modify libvirt to use query-cpu-state if it's available,
   otherwise use query-cpus (in which case "halted" will be bogus,
   but that's a feature :) )

In essence, we're moving the arch-specific code from libvirt to
qemu.