On 08/08/2012 08:25 PM, Andreas Färber wrote:
Am 31.01.2012 15:01, schrieb Mitsyanko Igor:
On 01/31/2012 05:15 PM, Andreas Färber wrote:
Am 31.01.2012 00:53, schrieb Anthony Liguori:
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any
Am 31.01.2012 15:01, schrieb Mitsyanko Igor:
> On 01/31/2012 05:15 PM, Andreas Färber wrote:
>> Am 31.01.2012 00:53, schrieb Anthony Liguori:
>>> On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
> Please send in any agenda items you are interested i
On 03/12/2012 11:43 AM, Igor Mitsyanko wrote:
> On 02/21/2012 07:33 PM, Peter Maydell wrote:
>>
>> Short summary:
>> * switch wp groups to bitfield rather than int array
>> * convert sd.c to use memory_region_init_ram() to allocate the wp
>> groups
>> (being careful to use memory_region_set_dir
On 03/12/2012 01:43 PM, Igor Mitsyanko wrote:
On 02/21/2012 07:33 PM, Peter Maydell wrote:
Short summary:
* switch wp groups to bitfield rather than int array
* convert sd.c to use memory_region_init_ram() to allocate the wp groups
(being careful to use memory_region_set_dirty() when we touch t
On 02/21/2012 07:33 PM, Peter Maydell wrote:
Short summary:
* switch wp groups to bitfield rather than int array
* convert sd.c to use memory_region_init_ram() to allocate the wp groups
(being careful to use memory_region_set_dirty() when we touch them)
* we don't need variable-length fiel
On Mon, 5 Mar 2012, Blue Swirl wrote:
> On Mon, Mar 5, 2012 at 15:17, Avi Kivity wrote:
> > On 03/05/2012 05:15 PM, Anthony Liguori wrote:
> >>> The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory
> >>> API. I think 32-on-32 is quite rare these days, so it wouldn't be much
>
On Mon, Mar 5, 2012 at 15:17, Avi Kivity wrote:
> On 03/05/2012 05:15 PM, Anthony Liguori wrote:
>>> The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory
>>> API. I think 32-on-32 is quite rare these days, so it wouldn't be much
>>> of a performance issue.
>>
>>
>> I think thi
On 03/05/2012 05:50 PM, Peter Maydell wrote:
> On 5 March 2012 15:43, Andreas Färber wrote:
> > Mid-term also depends on how me want to proceed with LPAE softmmu-wise
> > (bump "arm" to 64-bit target_phys_addr_t, or do LPAE and AArch64 in a
> > new "arm64").
>
> For LPAE I would have thought we wa
On 5 March 2012 15:43, Andreas Färber wrote:
> Mid-term also depends on how me want to proceed with LPAE softmmu-wise
> (bump "arm" to 64-bit target_phys_addr_t, or do LPAE and AArch64 in a
> new "arm64").
For LPAE I would have thought we want to make "arm" go to a 64 bit
target_phys_addr_t, sinc
On 03/05/2012 05:43 PM, Andreas Färber wrote:
> Am 05.03.2012 16:10, schrieb Avi Kivity:
> > On 03/05/2012 04:37 PM, Igor Mitsyanko wrote:
> >>> Well, can't you make sd.c target dependent? It's not so nice, but it
> >>> does solve the problem.
> >>>
> >>
> >> OK, but it will turn qemu from it's "l
Am 05.03.2012 16:10, schrieb Avi Kivity:
> On 03/05/2012 04:37 PM, Igor Mitsyanko wrote:
>>> Well, can't you make sd.c target dependent? It's not so nice, but it
>>> does solve the problem.
>>>
>>
>> OK, but it will turn qemu from it's "long term path to suppress *all*
>> target specific code" :)
On 5 March 2012 15:21, Avi Kivity wrote:
> On 03/05/2012 05:20 PM, Peter Maydell wrote:
>> On 5 March 2012 15:10, Avi Kivity wrote:
>> > I think 32-on-32 is quite rare these days, so it wouldn't be much
>> > of a performance issue.
>>
>> 32-on-32 will be the standard case for KVM on ARM I think..
On 03/05/2012 05:20 PM, Peter Maydell wrote:
> On 5 March 2012 15:10, Avi Kivity wrote:
> > I think 32-on-32 is quite rare these days, so it wouldn't be much
> > of a performance issue.
>
> 32-on-32 will be the standard case for KVM on ARM I think...
Won't we be virtualizing LPAE per default?
--
On 5 March 2012 15:10, Avi Kivity wrote:
> I think 32-on-32 is quite rare these days, so it wouldn't be much
> of a performance issue.
32-on-32 will be the standard case for KVM on ARM I think...
-- PMM
On 03/05/2012 05:15 PM, Anthony Liguori wrote:
>> The other alternative is to s/target_phys_addr_t/uint64_t/ in the memory
>> API. I think 32-on-32 is quite rare these days, so it wouldn't be much
>> of a performance issue.
>
>
> I think this makes sense independent of other discussions regarding
On 03/05/2012 09:10 AM, Avi Kivity wrote:
On 03/05/2012 04:37 PM, Igor Mitsyanko wrote:
Well, can't you make sd.c target dependent? It's not so nice, but it
does solve the problem.
OK, but it will turn qemu from it's "long term path to suppress *all*
target specific code" :)
The other alt
On 03/05/2012 04:37 PM, Igor Mitsyanko wrote:
>> Well, can't you make sd.c target dependent? It's not so nice, but it
>> does solve the problem.
>>
>
> OK, but it will turn qemu from it's "long term path to suppress *all*
> target specific code" :)
>
The other alternative is to s/target_phys_addr
On 03/05/2012 06:13 PM, Avi Kivity wrote:
On 03/05/2012 03:38 PM, Igor Mitsyanko wrote:
Short summary:
* switch wp groups to bitfield rather than int array
* convert sd.c to use memory_region_init_ram() to allocate the wp
groups
(being careful to use memory_region_set_dirty() when we touch
On 03/05/2012 03:38 PM, Igor Mitsyanko wrote:
>> Short summary:
>> * switch wp groups to bitfield rather than int array
>> * convert sd.c to use memory_region_init_ram() to allocate the wp
>> groups
>> (being careful to use memory_region_set_dirty() when we touch them)
>> * we don't need vari
On 02/21/2012 07:33 PM, Peter Maydell wrote:
On 9 February 2012 22:23, Peter Maydell wrote:
Ping re the VMState and variable sized arrays issue. I don't
see any consensus in this discussion for a different approach,
so should we just commit Mitsyanko's patchset?
From an IRC conversation I ju
On 02/21/2012 07:33 PM, Peter Maydell wrote:
Short summary:
* switch wp groups to bitfield rather than int array
* convert sd.c to use memory_region_init_ram() to allocate the wp groups
(being careful to use memory_region_set_dirty() when we touch them)
* we don't need variable-length field
On 9 February 2012 22:23, Peter Maydell wrote:
> Ping re the VMState and variable sized arrays issue. I don't
> see any consensus in this discussion for a different approach,
> so should we just commit Mitsyanko's patchset?
>From an IRC conversation I just had with Anthony and Juan:
===begin==
14
On 10.02.2012, at 00:17, Andreas Färber wrote:
> Am 09.02.2012 23:37, schrieb Anthony Liguori:
>> On 02/09/2012 04:23 PM, Peter Maydell wrote:
>>> Ping re the VMState and variable sized arrays issue. I don't
>>> see any consensus in this discussion for a different approach,
>>> so should we just
Am 09.02.2012 23:37, schrieb Anthony Liguori:
> On 02/09/2012 04:23 PM, Peter Maydell wrote:
>> Ping re the VMState and variable sized arrays issue. I don't
>> see any consensus in this discussion for a different approach,
>> so should we just commit Mitsyanko's patchset?
>
> I don't know if I men
On 9 February 2012 22:37, Anthony Liguori wrote:
> I don't know if I mentioned this, but do we really need variable sizes?
>
> Can we just use a fixed size (pre-allocated) array and then use a
> VMSTATE_SUB_ARRAY?
>
> If it's truly variable size with no upper bound, then that's actually a
> securi
On 02/09/2012 04:23 PM, Peter Maydell wrote:
Ping re the VMState and variable sized arrays issue. I don't
see any consensus in this discussion for a different approach,
so should we just commit Mitsyanko's patchset?
I don't know if I mentioned this, but do we really need variable sizes?
Can we
Ping re the VMState and variable sized arrays issue. I don't
see any consensus in this discussion for a different approach,
so should we just commit Mitsyanko's patchset?
- PMM
On 31 January 2012 13:15, Andreas Färber wrote:
> Am 31.01.2012 00:53, schrieb Anthony Liguori:
>> On 01/30/2012 05:41
Am 31.01.2012 14:59, schrieb Anthony Liguori:
> On 01/30/2012 05:41 PM, Andreas Färber wrote:
>> Am 30.01.2012 19:55, schrieb Juan Quintela:
>>> Please send in any agenda items you are interested in covering.
>>
>> QOM roadmap update:
>> * Series 3/4 is on the list.
>> -> Please officially designa
On 01/31/2012 03:12 PM, Anthony Liguori wrote:
Don't use VMState. Just open code a save/restore function. VMState is
too limited in how it handles complex data structures.
I really believe the only long term solution we're going to get to here
is something that uses a builder interface (like
On Tue, Jan 31, 2012 at 05:04:48PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 31, 2012 at 08:12:29AM -0600, Anthony Liguori wrote:
> > On 01/31/2012 07:15 AM, Andreas Färber wrote:
> > >Am 31.01.2012 00:53, schrieb Anthony Liguori:
> > >>On 01/30/2012 05:41 PM, Andreas Färber wrote:
> > >>>Am 3
On Tue, Jan 31, 2012 at 08:12:29AM -0600, Anthony Liguori wrote:
> On 01/31/2012 07:15 AM, Andreas Färber wrote:
> >Am 31.01.2012 00:53, schrieb Anthony Liguori:
> >>On 01/30/2012 05:41 PM, Andreas Färber wrote:
> >>>Am 30.01.2012 19:55, schrieb Juan Quintela:
> Please send in any agenda items
On 01/31/2012 04:17 PM, Anthony Liguori wrote:
> On 01/31/2012 08:09 AM, Avi Kivity wrote:
>> On 01/31/2012 03:59 PM, Anthony Liguori wrote:
>>> On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
> Please send in any agenda items you are interested in
On 01/31/2012 08:09 AM, Avi Kivity wrote:
On 01/31/2012 03:59 PM, Anthony Liguori wrote:
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
QOM roadmap update:
* Series 3/4 is on the list.
On 01/31/2012 07:15 AM, Andreas Färber wrote:
Am 31.01.2012 00:53, schrieb Anthony Liguori:
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
VMState:
Anthony specifically said that VMSta
On 01/31/2012 03:59 PM, Anthony Liguori wrote:
> On 01/30/2012 05:41 PM, Andreas Färber wrote:
>> Am 30.01.2012 19:55, schrieb Juan Quintela:
>>> Please send in any agenda items you are interested in covering.
>>
>> QOM roadmap update:
>> * Series 3/4 is on the list.
>> -> Please officially design
On 01/31/2012 05:15 PM, Andreas Färber wrote:
Am 31.01.2012 00:53, schrieb Anthony Liguori:
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
VMState:
Anthony specifically said that VMSta
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
QOM roadmap update:
* Series 3/4 is on the list.
-> Please officially designate a merge date (Friday?).
-> To make review sensible, I ask
Am 31.01.2012 00:53, schrieb Anthony Liguori:
> On 01/30/2012 05:41 PM, Andreas Färber wrote:
>> Am 30.01.2012 19:55, schrieb Juan Quintela:
>>> Please send in any agenda items you are interested in covering.
>> VMState:
>> Anthony specifically said that VMState were not affected by QOM and that
>
Anthony Liguori writes:
> On 01/30/2012 05:41 PM, Andreas Färber wrote:
>>
>> Mascot contest:
>> Any update? Were there too few entries? Has it been forgotten?
>> If the contest is still open then that should be stated on the list.
> Yes, I'm falling victim to perfectionism here attempting to fi
On 31.01.2012, at 00:53, Anthony Liguori wrote:
> On 01/30/2012 05:41 PM, Andreas Färber wrote:
>> Am 30.01.2012 19:55, schrieb Juan Quintela:
>>> Please send in any agenda items you are interested in covering.
>>
>> QOM roadmap update:
>> * Series 3/4 is on the list.
>> -> Please officially de
On 01/30/2012 05:41 PM, Andreas Färber wrote:
Am 30.01.2012 19:55, schrieb Juan Quintela:
Please send in any agenda items you are interested in covering.
QOM roadmap update:
* Series 3/4 is on the list.
-> Please officially designate a merge date (Friday?).
-> To make review sensible, I ask
Am 30.01.2012 19:55, schrieb Juan Quintela:
> Please send in any agenda items you are interested in covering.
QOM roadmap update:
* Series 3/4 is on the list.
-> Please officially designate a merge date (Friday?).
-> To make review sensible, I ask for a hard device freeze until merged.
I.e., no
hi
Please send in any agenda items you are interested in covering.
Cheers,
Juan.
43 matches
Mail list logo
