On 10/11/19 15:00, Michael S. Tsirkin wrote:
> On Fri, Oct 11, 2019 at 10:01:42AM +0200, Laszlo Ersek wrote:
[...]
>> ... I must admit: I didn't expect this, but now I've grown to *prefer*
>> the CPU hotplug register block!
>
> OK, send an ack then.
This RFC isn't mature enough for an ACK, but
On Fri, Oct 11, 2019 at 10:01:42AM +0200, Laszlo Ersek wrote:
> On 10/10/19 21:20, Eduardo Habkost wrote:
> > On Thu, Oct 10, 2019 at 05:57:54PM +0200, Igor Mammedov wrote:
> >> On Thu, 10 Oct 2019 09:59:42 -0400
> >> "Michael S. Tsirkin" wrote:
> >>
> >>> On Thu, Oct 10, 2019 at 03:39:12PM +0200,
On Thu, 10 Oct 2019 16:20:39 -0300
Eduardo Habkost wrote:
> On Thu, Oct 10, 2019 at 05:57:54PM +0200, Igor Mammedov wrote:
> > On Thu, 10 Oct 2019 09:59:42 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
> > > > On Thu, 10 Oct 2
On 10/10/19 21:20, Eduardo Habkost wrote:
> On Thu, Oct 10, 2019 at 05:57:54PM +0200, Igor Mammedov wrote:
>> On Thu, 10 Oct 2019 09:59:42 -0400
>> "Michael S. Tsirkin" wrote:
>>
>>> On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
On Thu, 10 Oct 2019 05:56:55 -0400
"Michae
On 10/10/19 20:15, Michael S. Tsirkin wrote:
> 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
>>
On 10/10/19 17:57, Igor Mammedov wrote:
> On Thu, 10 Oct 2019 09:59:42 -0400
> "Michael S. Tsirkin" wrote:
>
>> On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
>>> On Thu, 10 Oct 2019 05:56:55 -0400
>>> "Michael S. Tsirkin" wrote:
>>>
On Wed, Oct 09, 2019 at 09:22:49AM -0400,
On Thu, Oct 10, 2019 at 05:57:54PM +0200, Igor Mammedov wrote:
> On Thu, 10 Oct 2019 09:59:42 -0400
> "Michael S. Tsirkin" wrote:
>
> > On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
> > > On Thu, 10 Oct 2019 05:56:55 -0400
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Wed,
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 ac
On Thu, 10 Oct 2019 11:16:52 -0300
Eduardo Habkost wrote:
> On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
> > On Thu, 10 Oct 2019 05:56:55 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote:
> > > > As an alternative to
On Thu, 10 Oct 2019 09:59:42 -0400
"Michael S. Tsirkin" wrote:
> On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
> > On Thu, 10 Oct 2019 05:56:55 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote:
> > > > As an alternati
On Thu, Oct 10, 2019 at 11:16:52AM -0300, Eduardo Habkost wrote:
> On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
> > On Thu, 10 Oct 2019 05:56:55 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote:
> > > > As an alternati
On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
> On Thu, 10 Oct 2019 05:56:55 -0400
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote:
> > > As an alternative to passing to firmware topology info via new fwcfg files
> > > so it could
On Thu, Oct 10, 2019 at 03:39:12PM +0200, Igor Mammedov wrote:
> On Thu, 10 Oct 2019 05:56:55 -0400
> "Michael S. Tsirkin" wrote:
>
> > On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote:
> > > As an alternative to passing to firmware topology info via new fwcfg files
> > > so it could
On Thu, 10 Oct 2019 05:56:55 -0400
"Michael S. Tsirkin" wrote:
> On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote:
> > As an alternative to passing to firmware topology info via new fwcfg files
> > so it could recreate APIC IDs based on it and order CPUs are enumerated,
> >
> > exte
On Wed, Oct 09, 2019 at 09:22:49AM -0400, Igor Mammedov wrote:
> As an alternative to passing to firmware topology info via new fwcfg files
> so it could recreate APIC IDs based on it and order CPUs are enumerated,
>
> extend CPU hotplug interface to return APIC ID as response to the new command
>
As an alternative to passing to firmware topology info via new fwcfg files
so it could recreate APIC IDs based on it and order CPUs are enumerated,
extend CPU hotplug interface to return APIC ID as response to the new command
CPHP_GET_CPU_ID_CMD.
CC: Laszlo Ersek
CC: Eduardo Habkost
CC: "Micha
16 matches
Mail list logo