On 30 April 2013 16:14, Igor Mammedov wrote:
> On Tue, 30 Apr 2013 15:54:34 +0100
> Peter Maydell wrote:
>> I think really if you want to know what the current CPU model
>> is you need to fish the relevant QOM qbject out from somewhere
>> at runtime.
>
> Ideally that QOM object would be QOMifyed
On Tue, 30 Apr 2013 15:54:34 +0100
Peter Maydell wrote:
> On 30 April 2013 15:30, Eduardo Habkost wrote:
> > My concern is that we already have a QEMUMachineInitArgs.cpu_model
> > field, and now QEMUMachine.cpu_model and QEMUMachineInitArgs.cpu_model
> > are redundant.
> >
> > To make it worse,
On 30 April 2013 15:30, Eduardo Habkost wrote:
> My concern is that we already have a QEMUMachineInitArgs.cpu_model
> field, and now QEMUMachine.cpu_model and QEMUMachineInitArgs.cpu_model
> are redundant.
>
> To make it worse, both variables can disagree with each other because we
> have other co
On Tue, Apr 30, 2013 at 03:41:26PM +0200, Igor Mammedov wrote:
> 1. Use default cpu_model from machine if user haven't provided it.
>It will allow statically define default cpu_model instead of
>dynamically setting default value.
> 2. Provides globally accessible cpu_model via current_machi
1. Use default cpu_model from machine if user haven't provided it.
It will allow statically define default cpu_model instead of
dynamically setting default value.
2. Provides globally accessible cpu_model via current_machine pointer.
Signed-off-by: Igor Mammedov
---
Note:
1. it will allow
