qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Krempa <pkrempa@redhat.com>,
	libvir-list@redhat.com, qemu-devel@nongnu.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Jiri Denemark <jdenemar@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
Date: Tue, 06 May 2014 22:29:24 +0200	[thread overview]
Message-ID: <53694624.7050603@suse.de> (raw)
In-Reply-To: <20140506201957.GW3363@otherpad.lan.raisama.net>

Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
>> On Tue, 6 May 2014 11:42:56 -0300
>> Eduardo Habkost <ehabkost@redhat.com> wrote:
>>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
>>>> On Fri, 2 May 2014 11:43:05 -0300
>>>> Eduardo Habkost <ehabkost@redhat.com> wrote:
>>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
>>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
>>>>>> Eduardo Habkost <ehabkost@redhat.com> wrote:
>>>>>>> This series allows management code to use object-add on X86CPU subclasses, so it
>>>>>> Is there any reason why "device-add" couldn't be used?
>>>>> It needs to work with "-machine none", device_add requires a bus to
>>>>> exist, and there is no icc-bus on machine_none.
>>>> The thing is that CPUID is a function of machine so using
>>>> "-machine none" will provide only approximately accurate data.
>>>> I'm not sure that retrieved possibly not accurate data are useful
>>>> for libvirt.
>>> "-cpu host" doesn't depend on machine, and is the most important thing
>>> right now (because libvirt's checks for host QEMU/kernel/CPU
>>> capabilities is completely broken).
>> true, but device-add/-cpu host could be used right now to get the
>> same CPUID data wile using any machine type or default one without
>> any of this patches.
> 
> device_add can't be used with "-machine none".

I see no reason why we couldn't *make* CPUs work on -machine none. The
ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
SysBus; if that prohibits other valid uses now, then evaluating Igor's
memory work for CPU might be an option.

I'm not aware of any real X86CPU dependency on ICCBus, so we might as
well make -device place it on SysBus if no ICCBus is available...
probably much more invasive and potentially dangerous though.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2014-05-06 20:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1398889773-14652-1-git-send-email-ehabkost@redhat.com>
2014-05-02 13:45 ` [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing Igor Mammedov
2014-05-02 14:43   ` Eduardo Habkost
2014-05-02 14:54     ` Paolo Bonzini
2014-05-02 16:43       ` Eduardo Habkost
2014-05-06  7:22     ` Igor Mammedov
2014-05-06 14:42       ` Eduardo Habkost
2014-05-06 20:01         ` Igor Mammedov
2014-05-06 20:19           ` Eduardo Habkost
2014-05-06 20:29             ` Andreas Färber [this message]
2014-05-08 18:29               ` Eduardo Habkost
2014-05-15 12:35               ` Igor Mammedov
2014-05-15 13:07                 ` Eduardo Habkost
2014-05-15 13:09                   ` Andreas Färber
2014-05-15 13:48                   ` Igor Mammedov
2014-05-15 14:03                     ` Eduardo Habkost
2014-05-16 14:52                       ` Igor Mammedov
2014-05-16 15:16                         ` Eduardo Habkost
2014-05-16 14:57                 ` Andreas Färber
2014-05-06 22:13             ` [Qemu-devel] [libvirt] " Eric Blake
2014-05-15 12:14             ` [Qemu-devel] " Igor Mammedov
2014-05-15 13:35               ` Eduardo Habkost
     [not found] ` <1398889773-14652-2-git-send-email-ehabkost@redhat.com>
2014-05-15 12:28   ` [Qemu-devel] [RFC 1/5] cpu: Initialize cpu->stopped=true earlier 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=53694624.7050603@suse.de \
    --to=afaerber@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=pkrempa@redhat.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 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).