On Fri, Dec 08, 2017 at 06:32:03PM +0100, Igor Mammedov wrote:
> On Fri, 8 Dec 2017 14:14:22 -0200
> Eduardo Habkost wrote:
>
> > On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote:
> > > On Fri, 8 Dec 2017 13:19:27 +
> > > Peter Maydell wrote:
> > >
> > > > On 8 December 2017
On Fri, 8 Dec 2017 14:14:22 -0200
Eduardo Habkost wrote:
> On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote:
> > On Fri, 8 Dec 2017 13:19:27 +
> > Peter Maydell wrote:
> >
> > > On 8 December 2017 at 13:16, Igor Mammedov wrote:
> > > > TBH:
> > > > I do not recall why we
On Fri, Dec 08, 2017 at 03:50:50PM +0100, Igor Mammedov wrote:
> On Fri, 8 Dec 2017 13:19:27 +
> Peter Maydell wrote:
>
> > On 8 December 2017 at 13:16, Igor Mammedov wrote:
> > > TBH:
> > > I do not recall why we have x86 max/host cpu types do feature
> > > loading at realize time instead
On 8 December 2017 at 14:50, Igor Mammedov wrote:
> On Fri, 8 Dec 2017 13:19:27 +
> Peter Maydell wrote:
>
>> On 8 December 2017 at 13:16, Igor Mammedov wrote:
>> > TBH:
>> > I do not recall why we have x86 max/host cpu types do feature
>> > loading at realize time instead of at class init
On Fri, 8 Dec 2017 13:19:27 +
Peter Maydell wrote:
> On 8 December 2017 at 13:16, Igor Mammedov wrote:
> > TBH:
> > I do not recall why we have x86 max/host cpu types do feature
> > loading at realize time instead of at class init like the rest
> > of static cpu types.
>
> class init i
On 8 December 2017 at 13:16, Igor Mammedov wrote:
> TBH:
> I do not recall why we have x86 max/host cpu types do feature
> loading at realize time instead of at class init like the rest
> of static cpu types.
class init is too early, IIRC -- it's before KVM has been set up at all.
thanks
-- P
On Thu, 7 Dec 2017 17:26:53 +
Peter Maydell wrote:
> On 7 December 2017 at 17:13, Peter Maydell wrote:
> > On 7 December 2017 at 17:07, Eduardo Habkost wrote:
> >> On Thu, Dec 07, 2017 at 04:53:59PM +, Peter Maydell wrote:
> >>> On 7 December 2017 at 16:48, Igor Mammedov wrote:
>
On 7 December 2017 at 17:13, Peter Maydell wrote:
> On 7 December 2017 at 17:07, Eduardo Habkost wrote:
>> On Thu, Dec 07, 2017 at 04:53:59PM +, Peter Maydell wrote:
>>> On 7 December 2017 at 16:48, Igor Mammedov wrote:
>>> > On Thu, 7 Dec 2017 16:05:50 +
>>> > Peter Maydell wrote:
>>>
On 7 December 2017 at 17:07, Eduardo Habkost wrote:
> On Thu, Dec 07, 2017 at 04:53:59PM +, Peter Maydell wrote:
>> On 7 December 2017 at 16:48, Igor Mammedov wrote:
>> > On Thu, 7 Dec 2017 16:05:50 +
>> > Peter Maydell wrote:
>> >
>> >> Hi; I'm currently writing '-cpu max' support for A
On Thu, Dec 07, 2017 at 04:53:59PM +, Peter Maydell wrote:
> On 7 December 2017 at 16:48, Igor Mammedov wrote:
> > On Thu, 7 Dec 2017 16:05:50 +
> > Peter Maydell wrote:
> >
> >> Hi; I'm currently writing '-cpu max' support for ARM. For that I'd
> >> like to be able to do the "probe host
On 7 December 2017 at 16:48, Igor Mammedov wrote:
> On Thu, 7 Dec 2017 16:05:50 +
> Peter Maydell wrote:
>
>> Hi; I'm currently writing '-cpu max' support for ARM. For that I'd
>> like to be able to do the "probe host kernel for its supported feature
>> set" in the CPU object's instance-init
On Thu, 7 Dec 2017 16:05:50 +
Peter Maydell wrote:
> Hi; I'm currently writing '-cpu max' support for ARM. For that I'd
> like to be able to do the "probe host kernel for its supported feature
> set" in the CPU object's instance-init function, but I'd like to do
> it just once and cache the a
Hi; I'm currently writing '-cpu max' support for ARM. For that I'd
like to be able to do the "probe host kernel for its supported feature
set" in the CPU object's instance-init function, but I'd like to do
it just once and cache the answer. Can I rely on something or other
having the BQL or otherwi
13 matches
Mail list logo
