From: Anthony Liguori <anthony@codemonkey.ws>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Chris Wright" <chrisw@redhat.com>,
"Developers qemu-devel" <qemu-devel@nongnu.org>,
"Andreas Färber" <afaerber@suse.de>,
"KVM devel mailing list" <kvm@vger.kernel.org>,
quintela@redhat.com
Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 3
Date: Tue, 03 Jan 2012 07:37:49 -0600 [thread overview]
Message-ID: <4F0304AD.6010800@codemonkey.ws> (raw)
In-Reply-To: <CAFEAcA_-riDTSC+LTa7651b6vcxnpbMMnGKtNK4x5tP=Ve0zRA@mail.gmail.com>
On 01/03/2012 04:26 AM, Peter Maydell wrote:
> On 3 January 2012 01:14, Anthony Liguori<anthony@codemonkey.ws> wrote:
>> Let's separate out what a user *should* do from what a user *can* do.
>>
>> A user *should* have a command line syntax that reflects something that
>> makes sense to them. For instance, qemu-system-arm --machine beaglebone
>>
>> I don't really care what the SoC or CPU in my beaglebone is. I just want to
>> emulate one.
>>
>> But I do believe we want to make it possible for -device to create a CPU
>> even when it doesn't make sense.
>
> So there's a couple of things here that fall in the "can't do that" bin:
>
> 1. trying to instantiate more than one device which has a CPU in it
> (eg the default one from the machine/SoC model, and the second one
> from the -device my-soc command line argument). (Basic QEMU limitation.)
But this is something that shouldn't be a limitation IMHO.
> 2. trying to replace an existing device in the machine model with a
> different one which isn't connection-compatible with it.
So for the PC, I imagine we would have something like a
socket[0]:link<X86CPUState> property. You would set topology by setting
properties to make a single CPU appear to have multiple cores/threads.
For what you're getting at, you actually want to model the CPUs in QOM such that
you would have an ARM926 is-a ARMCPU is-a CPUCommon.
Then you could have the beagle machine have a link<ARM926>. If it always has a
single CPU, you make it a child<ARM926> and the user can't change it.
They can still set properties on the CPU so if there are flags they need to
tweak, they could.
> For instance,
> in a fully QOM world, trying to run a beagle machine with (say) a 926
> CPU should fail to instantiate, because the 926 CPU won't have the right
> set of irq/gpio inputs and outputs that the beagle machine needs to
> connect up to. (This is the QOM equivalent of trying to ram a 486
> into a Pentium CPU socket.)
>
> I don't think we even have syntax for 2 at the moment except for the
> weird special case of "-cpu foo".
Yeah, it's still not clear to me how much we want to model CPUs in QOM. We
could do it very simply and flat or model the individual CPUs as proper types
which lets you do fancier things with links.
Regards,
Anthony Liguori
> -- PMM
>
next prev parent reply other threads:[~2012-01-03 13:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-02 12:09 [Qemu-devel] KVM call agenda for Tuesday 3 Juan Quintela
2012-01-02 13:46 ` Andreas Färber
2012-01-02 14:11 ` Paolo Bonzini
2012-01-03 1:12 ` Anthony Liguori
2012-01-03 8:54 ` Paolo Bonzini
2012-01-02 15:54 ` Peter Maydell
2012-01-03 1:14 ` Anthony Liguori
2012-01-03 10:26 ` Peter Maydell
2012-01-03 12:07 ` Alex Bradbury
2012-01-03 13:37 ` Anthony Liguori [this message]
2012-01-03 13:57 ` Peter Maydell
2012-01-03 14:02 ` Anthony Liguori
2012-01-03 14:13 ` Peter Maydell
2012-01-03 1:04 ` Anthony Liguori
2012-01-03 13:52 ` Andreas Färber
2012-01-03 13:59 ` Anthony Liguori
2012-01-03 8:33 ` Stefan Hajnoczi
2012-01-03 12:15 ` Dor Laor
2012-01-03 13:12 ` Stefan Hajnoczi
2012-01-03 14:10 ` Andreas Färber
2012-01-03 14:30 ` Vadim Rozenfeld
2012-01-04 2:47 ` Cao,Bing Bu
2012-01-04 11:25 ` Stefan Hajnoczi
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=4F0304AD.6010800@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=afaerber@suse.de \
--cc=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=peter.maydell@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).