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 in covering.
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
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_dirty() when we
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
an IRC conversation I just had with Anthony and Juan:
===begin==
14:51 pm215 quintela: do you have an opinion on the vmstate variable-
length array stuff (needed for sd card) ?
14:51 quintela pm havent looked, email title?
14:52 pm215 KVM call agenda for tuesday 31 is the most recent
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 variable-length
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
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
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
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
fixing
On 5 March 2012 15:10, Avi Kivity a...@redhat.com 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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of
On 03/05/2012 05:20 PM, Peter Maydell wrote:
On 5 March 2012 15:10, Avi Kivity a...@redhat.com 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
On 5 March 2012 15:21, Avi Kivity a...@redhat.com wrote:
On 03/05/2012 05:20 PM, Peter Maydell wrote:
On 5 March 2012 15:10, Avi Kivity a...@redhat.com 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
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 :)
The other
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 long term path to
On 5 March 2012 15:43, Andreas Färber afaer...@suse.de 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
On 03/05/2012 05:50 PM, Peter Maydell wrote:
On 5 March 2012 15:43, Andreas Färber afaer...@suse.de 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
On Mon, Mar 5, 2012 at 15:17, Avi Kivity a...@redhat.com 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
On Mon, 5 Mar 2012, Blue Swirl wrote:
On Mon, Mar 5, 2012 at 15:17, Avi Kivity a...@redhat.com 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
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
and Juan:
===begin==
14:51 pm215 quintela: do you have an opinion on the vmstate variable-
length array stuff (needed for sd card) ?
14:51 quintela pm havent looked, email title?
14:52 pm215 KVM call agenda for tuesday 31 is the most recent
discussion :-)
14:53 pm215 http://patchwork.ozlabs.org
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 afaer...@suse.de wrote:
Am 31.01.2012 00:53, schrieb Anthony Liguori:
On
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
On 9 February 2012 22:37, Anthony Liguori anth...@codemonkey.ws 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
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 mentioned
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 commit
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
patches
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
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
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 designate a merge
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
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 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 covering.
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 you are
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 30.01.2012
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
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 designate a merge
hi
Please send in any agenda items you are interested in covering.
Cheers,
Juan.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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 designate a
42 matches
Mail list logo
