On Wed, Dec 16, 2015 at 06:22:20PM +0100, Igor Mammedov wrote:
> On Wed, 16 Dec 2015 16:57:54 +0100
> Andreas Färber wrote:
>
> > Am 16.12.2015 um 16:44 schrieb Igor Mammedov:
> > > On Wed, 16 Dec 2015 16:19:06 +0100
> > > Andreas Färber wrote:
> > >
> > >> Am 10.12.2015 um 07:15 schrieb Bharat
On Fri, 1 Jan 2016 09:17:48 +0530
Bharata B Rao wrote:
> On Wed, Dec 16, 2015 at 04:46:37PM +0100, Andreas Färber wrote:
> > Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
> > > wrt CLI can't we do something like this?
> > >
> > > -device some-cpu-model,socket=x[,core=y[,thread=z]]
> >
> > T
On Wed, Dec 16, 2015 at 04:46:37PM +0100, Andreas Färber wrote:
> Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
> > wrt CLI can't we do something like this?
> >
> > -device some-cpu-model,socket=x[,core=y[,thread=z]]
>
> That's problematic and where my x86 remodeling got stuck. It works fine
> (m
On Thu, 24 Dec 2015 09:59:53 +0800
Zhu Guihua wrote:
>
> On 12/17/2015 05:58 AM, Igor Mammedov wrote:
> > On Wed, 16 Dec 2015 16:46:37 +0100
> > Andreas Färber wrote:
> >
> >> Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
> >>> wrt CLI can't we do something like this?
> >>>
> >>> -device some-c
On 12/17/2015 05:58 AM, Igor Mammedov wrote:
On Wed, 16 Dec 2015 16:46:37 +0100
Andreas Färber wrote:
Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
wrt CLI can't we do something like this?
-device some-cpu-model,socket=x[,core=y[,thread=z]]
That's problematic and where my x86 remodeling go
On Wed, Dec 16, 2015 at 16:11:08 +0100, Igor Mammedov wrote:
> On Fri, 11 Dec 2015 09:27:57 +0530
> Bharata B Rao wrote:
>
> > On Thu, Dec 10, 2015 at 01:35:05PM +0100, Igor Mammedov wrote:
> > > On Thu, 10 Dec 2015 11:45:35 +0530
> > > Bharata B Rao wrote:
[...]
> > > For initial conversion o
On Wed, 16 Dec 2015 18:22:20 +0100
Igor Mammedov wrote:
> On Wed, 16 Dec 2015 16:57:54 +0100
> Andreas Färber wrote:
[...]
> >
> > Attendees in Seattle said that thread-level hot-plug were dangerous
> > for Linux guests due to assumptions in the (guest's) scheduler
> > breaking for any incomple
On Wed, 16 Dec 2015 16:46:37 +0100
Andreas Färber wrote:
> Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
> > wrt CLI can't we do something like this?
> >
> > -device some-cpu-model,socket=x[,core=y[,thread=z]]
>
> That's problematic and where my x86 remodeling got stuck. It works
> fine (more o
On Wed, 16 Dec 2015 16:57:54 +0100
Andreas Färber wrote:
> Am 16.12.2015 um 16:44 schrieb Igor Mammedov:
> > On Wed, 16 Dec 2015 16:19:06 +0100
> > Andreas Färber wrote:
> >
> >> Am 10.12.2015 um 07:15 schrieb Bharata B Rao:
> >>> CPU hotplug granularity
> >>> ---
> >>> CPU
Am 16.12.2015 um 16:44 schrieb Igor Mammedov:
> On Wed, 16 Dec 2015 16:19:06 +0100
> Andreas Färber wrote:
>
>> Am 10.12.2015 um 07:15 schrieb Bharata B Rao:
>>> CPU hotplug granularity
>>> ---
>>> CPU hotplug will now be done in cpu-core device granularity.
>>
>> Nack.
>>
>>>
Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
> wrt CLI can't we do something like this?
>
> -device some-cpu-model,socket=x[,core=y[,thread=z]]
That's problematic and where my x86 remodeling got stuck. It works fine
(more or less) to model sockets, cores and hyperthreads for -smp, but
doing it d
On Wed, 16 Dec 2015 16:19:06 +0100
Andreas Färber wrote:
> Am 10.12.2015 um 07:15 schrieb Bharata B Rao:
> > CPU hotplug granularity
> > ---
> > CPU hotplug will now be done in cpu-core device granularity.
>
> Nack.
>
> > Are there archs that would need thread level CPU addi
Am 10.12.2015 um 07:15 schrieb Bharata B Rao:
> CPU hotplug granularity
> ---
> CPU hotplug will now be done in cpu-core device granularity.
Nack.
> Are there archs that would need thread level CPU addition ?
Yes, s390. And for x86 people called for socket level.
Andreas
--
Am 15.12.2015 um 06:27 schrieb Zhu Guihua:
>
>>> and allow individual targets to use its own way to build CPUs?
>>>
>>> For initial conversion of x86-cpus to device-add we could do pretty
>>> much the same like we do now, where cpu devices will appear under:
>>> /machine (pc-i440fx-2.5-machine)
>>
On Fri, 11 Dec 2015 09:27:57 +0530
Bharata B Rao wrote:
> On Thu, Dec 10, 2015 at 01:35:05PM +0100, Igor Mammedov wrote:
> > On Thu, 10 Dec 2015 11:45:35 +0530
> > Bharata B Rao wrote:
> >
> > > Hi,
> > >
> > > This is an attempt to define a generic CPU device that serves as a
> > > containing
and allow individual targets to use its own way to build CPUs?
For initial conversion of x86-cpus to device-add we could do pretty
much the same like we do now, where cpu devices will appear under:
/machine (pc-i440fx-2.5-machine)
/unattached (container)
/device[x] (qemu64-x86_64-cpu)
On Thu, Dec 10, 2015 at 03:25:53PM -0500, Matthew Rosato wrote:
> On 12/10/2015 01:15 AM, Bharata B Rao wrote:
> > Hi,
> >
> > This is an attempt to define a generic CPU device that serves as a
> > containing device to underlying arch-specific CPU devices. The motivation
> > for this is to have an
On Thu, Dec 10, 2015 at 01:35:05PM +0100, Igor Mammedov wrote:
> On Thu, 10 Dec 2015 11:45:35 +0530
> Bharata B Rao wrote:
>
> > Hi,
> >
> > This is an attempt to define a generic CPU device that serves as a
> > containing device to underlying arch-specific CPU devices. The
> > motivation for th
On 12/10/2015 01:15 AM, Bharata B Rao wrote:
> Hi,
>
> This is an attempt to define a generic CPU device that serves as a
> containing device to underlying arch-specific CPU devices. The motivation
> for this is to have an arch-neutral way to specify CPUs mainly during
> hotplug.
>
> Instead of i
On Thu, 10 Dec 2015 11:45:35 +0530
Bharata B Rao wrote:
> Hi,
>
> This is an attempt to define a generic CPU device that serves as a
> containing device to underlying arch-specific CPU devices. The
> motivation for this is to have an arch-neutral way to specify CPUs
> mainly during hotplug.
>
>
Hi,
This is an attempt to define a generic CPU device that serves as a
containing device to underlying arch-specific CPU devices. The motivation
for this is to have an arch-neutral way to specify CPUs mainly during
hotplug.
Instead of individual archs having their own semantics to specify the
CPU
21 matches
Mail list logo