All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: "Andreas Färber" <afaerber@suse.de>,
	quintela@redhat.com, qemu-devel <qemu-devel@nongnu.org>,
	"KVM devel mailing list" <kvm@vger.kernel.org>,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06)
Date: Thu, 8 Aug 2013 22:16:18 +0100	[thread overview]
Message-ID: <CAFEAcA8mQg3N4sgfnUVtpe9C43JnjyGH1aKhXSdcLxAXk9thFQ@mail.gmail.com> (raw)
In-Reply-To: <20130808205714.GC16694@cbox>

On 8 August 2013 21:57, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> I'm fine with having a discovery mechanism for the GIC and not for the
> CPU, if there's an implicit discovery mechanism for the CPU.  But are
> we sure there will not be cases where we want to know the list of
> available CPUs that the kernel can actually emulate on this host as
> opposed to "just use the best one".

I guess "telling the user in advance whether enabling kvm is
going to work" (either via -help output or via monitor to
tell libvirt about it) might want that, and for that matter
maybe kvmtool might want to present a list of available CPUs.

(I probably wouldn't implement the 'say if it's going to
work in -help' bit immediately though because QEMU's internal
structure makes it a little awkward. But if we might want
it it's probably better for the kernel API to be there
from the start.)

-- PMM

WARNING: multiple messages have this Message-ID (diff)
From: Peter Maydell <peter.maydell@linaro.org>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	kvmarm@lists.cs.columbia.edu, "Andreas Färber" <afaerber@suse.de>,
	"KVM devel mailing list" <kvm@vger.kernel.org>,
	quintela@redhat.com
Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06)
Date: Thu, 8 Aug 2013 22:16:18 +0100	[thread overview]
Message-ID: <CAFEAcA8mQg3N4sgfnUVtpe9C43JnjyGH1aKhXSdcLxAXk9thFQ@mail.gmail.com> (raw)
In-Reply-To: <20130808205714.GC16694@cbox>

On 8 August 2013 21:57, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> I'm fine with having a discovery mechanism for the GIC and not for the
> CPU, if there's an implicit discovery mechanism for the CPU.  But are
> we sure there will not be cases where we want to know the list of
> available CPUs that the kernel can actually emulate on this host as
> opposed to "just use the best one".

I guess "telling the user in advance whether enabling kvm is
going to work" (either via -help output or via monitor to
tell libvirt about it) might want that, and for that matter
maybe kvmtool might want to present a list of available CPUs.

(I probably wouldn't implement the 'say if it's going to
work in -help' bit immediately though because QEMU's internal
structure makes it a little awkward. But if we might want
it it's probably better for the kernel API to be there
from the start.)

-- PMM

  reply	other threads:[~2013-08-08 21:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08 12:51 -cpu host (was Re: [Qemu-devel] KVM call minutes for 2013-08-06) Peter Maydell
2013-08-08 12:51 ` [Qemu-devel] -cpu host (was " Peter Maydell
2013-08-08 15:55 ` Andreas Färber
2013-08-08 15:55   ` Andreas Färber
2013-08-08 18:20   ` Peter Maydell
2013-08-08 18:20     ` Peter Maydell
2013-08-08 18:39     ` Christoffer Dall
2013-08-08 18:39       ` Christoffer Dall
2013-08-08 19:05       ` Peter Maydell
2013-08-08 19:05         ` Peter Maydell
2013-08-08 19:29         ` Christoffer Dall
2013-08-08 19:29           ` Christoffer Dall
2013-08-08 20:48           ` Peter Maydell
2013-08-08 20:48             ` Peter Maydell
2013-08-08 20:57             ` Christoffer Dall
2013-08-08 20:57               ` Christoffer Dall
2013-08-08 21:16               ` Peter Maydell [this message]
2013-08-08 21:16                 ` Peter Maydell
2013-08-09 17:53           ` Eduardo Habkost
2013-08-09 17:53             ` Eduardo Habkost
2013-08-25 13:49             ` Gleb Natapov
2013-08-25 13:49               ` Gleb Natapov
2013-08-25 13:55     ` Gleb Natapov
2013-08-25 13:55       ` [Qemu-devel] " Gleb Natapov
2013-08-25 13:14   ` Gleb Natapov
2013-08-25 13:14     ` Gleb Natapov
2013-08-09 13:12 ` Peter Maydell
2013-08-09 20:07   ` Andreas Färber
2013-08-09 20:07     ` Andreas Färber

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=CAFEAcA8mQg3N4sgfnUVtpe9C43JnjyGH1aKhXSdcLxAXk9thFQ@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=afaerber@suse.de \
    --cc=christoffer.dall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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.