On Sun, Apr 25, 2010 at 05:17:55PM +0300, Avi Kivity wrote:
On 04/25/2010 04:57 PM, Jan Kiszka wrote:
It's still a good idea. The current API assumes that there will be only
one slot-based client (or that multiple clients will keep the refcount
themselves).
After the bytemap - multiple
On 04/24/2010 10:34 AM, Jan Kiszka wrote:
Marcelo Tosatti wrote:
Otherwise there is no way to differentiate between global and slot
specific logging, so for example
vga dirty log start
migration start
migration fail
Disables dirty logging for the vga slot.
This is not true (unless
Avi Kivity wrote:
On 04/24/2010 10:34 AM, Jan Kiszka wrote:
Marcelo Tosatti wrote:
Otherwise there is no way to differentiate between global and slot
specific logging, so for example
vga dirty log start
migration start
migration fail
Disables dirty logging for the vga slot.
On 04/25/2010 04:57 PM, Jan Kiszka wrote:
It's still a good idea. The current API assumes that there will be only
one slot-based client (or that multiple clients will keep the refcount
themselves).
After the bytemap - multiple bitmaps conversion this can be extended to
each client getting
Avi Kivity wrote:
On 04/25/2010 04:57 PM, Jan Kiszka wrote:
It's still a good idea. The current API assumes that there will be only
one slot-based client (or that multiple clients will keep the refcount
themselves).
After the bytemap - multiple bitmaps conversion this can be
extended to
On 04/25/2010 05:29 PM, Jan Kiszka wrote:
There isn't. But I don't like hidden breakage.
It's (so far) an unproblematic API property we can document. I don't
like changing APIs just for there might be the case that
I guess it's one of those agree to disagree things. I
Avi Kivity wrote:
On 04/25/2010 05:29 PM, Jan Kiszka wrote:
There isn't. But I don't like hidden breakage.
It's (so far) an unproblematic API property we can document. I don't
like changing APIs just for there might be the case that
I guess it's one of those agree to
On 04/25/2010 05:51 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 04/25/2010 05:29 PM, Jan Kiszka wrote:
There isn't. But I don't like hidden breakage.
It's (so far) an unproblematic API property we can document. I don't
like changing APIs just for there might be
Avi Kivity wrote:
On 04/25/2010 05:51 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 04/25/2010 05:29 PM, Jan Kiszka wrote:
There isn't. But I don't like hidden breakage.
It's (so far) an unproblematic API property we can document. I don't
like changing APIs just
On 04/25/2010 06:07 PM, Jan Kiszka wrote:
The fact that the API assumes a single user is what's broken IMO.
If the API were to take a memory slot as parameter you could say it is
the responsibility of the slot's owner to multiplex (and since vga has a
single owner, no need to multiplex). But
Avi Kivity wrote:
On 04/25/2010 06:07 PM, Jan Kiszka wrote:
The fact that the API assumes a single user is what's broken IMO.
If the API were to take a memory slot as parameter you could say it is
the responsibility of the slot's owner to multiplex (and since vga has a
single owner, no need
On 04/25/2010 07:42 PM, Jan Kiszka wrote:
Unrelated:
cpu_physical_sync_dirty_bitmap(isa_mem_base + 0xa, 0xa8000);
cpu_physical_sync_dirty_bitmap(isa_mem_base + 0xa8000, 0xb);
Will this sync to the right place (whatever those windows alias to)?
It should. Or
Marcelo Tosatti wrote:
Otherwise there is no way to differentiate between global and slot
specific logging, so for example
vga dirty log start
migration start
migration fail
Disables dirty logging for the vga slot.
This is not true (unless there is a bug): Migration logging is tracked
13 matches
Mail list logo
