All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
	"Laszlo Ersek" <lersek@redhat.com>,
	qemu-devel@nongnu.org, "Gerd Hoffmann" <kraxel@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [RFC 0/3] acpi: cphp: add CPHP_GET_CPU_ID_CMD command to cpu hotplug MMIO interface
Date: Thu, 10 Oct 2019 14:15:44 -0400	[thread overview]
Message-ID: <20191010140934-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20191010175754.7c62cf8f@Igors-MacBook-Pro>

On Thu, Oct 10, 2019 at 05:57:54PM +0200, Igor Mammedov wrote:
> > Then we should consider switching acpi to use fw cfg.
> > Or build another interface that can scale.
> 
> Could be an option, it would be a pain to write a driver in AML for fwcfg access though
> (I've looked at possibility to access fwcfg from AML about a year ago and gave up.
> I'm definitely not volunteering for the second attempt and can't even give an estimate
> it it's viable approach).
> 
> But what scaling issue you are talking about, exactly?

Just this: each new thing we add is an ad-hoc data structure with
manually maintained backwards compatibility and no built-in discovery.

fw cfg has built-in discovery and we've finally managed to
handle compatibility reasonably well.

PV is already very problematic.  Spreading PV code all over the place
like this is a very bad idea.  For you CPU hotplug is something that you
keep in mind first of all, but someone bringing up a new platform
already has a steep hill to climb.  Adding tons of custom firmware is
not helping things.

-- 
MST


  reply	other threads:[~2019-10-10 18:24 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 13:22 [RFC 0/3] acpi: cphp: add CPHP_GET_CPU_ID_CMD command to cpu hotplug MMIO interface Igor Mammedov
2019-10-09 13:22 ` [RFC 1/3] acpi: cpuhp: fix 'Command data' description is spec Igor Mammedov
2019-10-10 12:33   ` Laszlo Ersek
2019-10-17 15:41     ` Igor Mammedov
2019-10-18 13:24       ` Laszlo Ersek
2019-10-10 13:31   ` Laszlo Ersek
2019-10-10 13:36     ` Laszlo Ersek
2019-10-22 17:17       ` Christophe de Dinechin
2019-10-22 17:37         ` Laszlo Ersek
2019-10-09 13:22 ` [RFC 2/3] acpi: cpuhp: add typical usecases into spec Igor Mammedov
2019-10-10 13:04   ` Laszlo Ersek
2019-10-10 13:15     ` Laszlo Ersek
2019-10-10 14:13   ` Laszlo Ersek
2019-10-18 14:45     ` Igor Mammedov
2019-10-09 13:22 ` [RFC 3/3] acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command Igor Mammedov
2019-10-10 14:56   ` Laszlo Ersek
2019-10-10 15:06     ` Michael S. Tsirkin
2019-10-10 17:23       ` Igor Mammedov
2019-10-10 17:53       ` Laszlo Ersek
2019-10-10 19:26       ` Eduardo Habkost
2019-10-11  8:07         ` Laszlo Ersek
2019-10-18 16:18     ` Igor Mammedov
2019-10-21 13:06       ` Laszlo Ersek
2019-10-22 12:39         ` Laszlo Ersek
2019-10-22 14:42           ` Igor Mammedov
2019-10-22 15:49             ` Laszlo Ersek
2019-10-23 14:59               ` Igor Mammedov
2019-10-24 15:07   ` Philippe Mathieu-Daudé
2019-10-10  9:56 ` [RFC 0/3] acpi: cphp: add CPHP_GET_CPU_ID_CMD command to cpu hotplug MMIO interface Michael S. Tsirkin
2019-10-10 13:39   ` Igor Mammedov
2019-10-10 13:59     ` Michael S. Tsirkin
2019-10-10 15:57       ` Igor Mammedov
2019-10-10 18:15         ` Michael S. Tsirkin [this message]
2019-10-11  7:41           ` Laszlo Ersek
2019-10-10 19:20         ` Eduardo Habkost
2019-10-11  8:01           ` Laszlo Ersek
2019-10-11 13:00             ` Michael S. Tsirkin
2019-10-11 16:13               ` Laszlo Ersek
2019-10-11 10:47           ` Igor Mammedov
2019-10-11  6:54         ` Laszlo Ersek
2019-10-10 14:16     ` Eduardo Habkost
2019-10-10 14:49       ` Michael S. Tsirkin
2019-10-10 17:09       ` 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=20191010140934-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.