On Wed, Jul 20, 2011 at 07:52:22PM +0300, Avi Kivity wrote:
On 07/20/2011 07:10 PM, Michael S. Tsirkin wrote:
and vga could do it if the vnc display
is disconnected, or if the update rate is so high it can just assume
all memory is dirty.
Yes, but it's not something *devices* should
On Tue, 2011-07-19 at 21:53 -0500, Anthony Liguori wrote:
QEMU does use it and it's quite important. Coalesced MMIO is really
about write caching MMIO exits. It only works with devices that have
registers where writing has no side effects. Moreover, it only really
works well when there
On 07/19/2011 11:51 PM, Anthony Liguori wrote:
On 07/19/2011 11:10 AM, Avi Kivity wrote:
On 07/19/2011 07:05 PM, Avi Kivity wrote:
On 07/19/2011 05:50 PM, Anthony Liguori wrote:
There's bits I don't like about the interface
Which bits are these?
Nothing I haven't already commented on.
On 07/20/2011 09:10 AM, Sasha Levin wrote:
On Tue, 2011-07-19 at 21:53 -0500, Anthony Liguori wrote:
QEMU does use it and it's quite important. Coalesced MMIO is really
about write caching MMIO exits. It only works with devices that have
registers where writing has no side effects.
On 07/19/2011 08:30 PM, Jan Kiszka wrote:
Rebasing is already not so fun for me with 78 patches and counting.
Let's drop yours and focus of getting mine in shape, since it's a superset.
The patches series are widely orthogonal except for both killing the
obsolete start/stop logging logic.
On 2011-07-20 10:13, Avi Kivity wrote:
On 07/19/2011 08:30 PM, Jan Kiszka wrote:
Rebasing is already not so fun for me with 78 patches and counting.
Let's drop yours and focus of getting mine in shape, since it's a superset.
The patches series are widely orthogonal except for both killing
On 2011-07-20 10:13, Avi Kivity wrote:
On 07/19/2011 08:30 PM, Jan Kiszka wrote:
Rebasing is already not so fun for me with 78 patches and counting.
Let's drop yours and focus of getting mine in shape, since it's a superset.
The patches series are widely orthogonal except for both killing
On 07/20/2011 01:10 AM, Sasha Levin wrote:
On Tue, 2011-07-19 at 21:53 -0500, Anthony Liguori wrote:
QEMU does use it and it's quite important. Coalesced MMIO is really
about write caching MMIO exits. It only works with devices that have
registers where writing has no side effects. Moreover,
On 07/20/2011 02:43 PM, Jan Kiszka wrote:
On 2011-07-20 10:13, Avi Kivity wrote:
On 07/19/2011 08:30 PM, Jan Kiszka wrote:
Rebasing is already not so fun for me with 78 patches and counting.
Let's drop yours and focus of getting mine in shape, since it's a
superset.
The patches
On 07/20/2011 02:20 PM, Jan Kiszka wrote:
On 2011-07-20 10:13, Avi Kivity wrote:
On 07/19/2011 08:30 PM, Jan Kiszka wrote:
Rebasing is already not so fun for me with 78 patches and counting.
Let's drop yours and focus of getting mine in shape, since it's a
superset.
The patches
On 2011-07-20 13:57, Avi Kivity wrote:
On 07/20/2011 02:43 PM, Jan Kiszka wrote:
On 2011-07-20 10:13, Avi Kivity wrote:
On 07/19/2011 08:30 PM, Jan Kiszka wrote:
Rebasing is already not so fun for me with 78 patches and counting.
Let's drop yours and focus of getting mine in shape, since
On 07/20/2011 04:57 PM, Jan Kiszka wrote:
Something around dirty logging is still seriously borken: when I boot
with standard or cirrus vga, the screen is not properly updated in
logged modes.
I don't see this here, will retest.
I bet the reason is lacking semantics of
On 07/20/2011 05:37 PM, Michael S. Tsirkin wrote:
If you do a memory_region_set_log() immediately after
memory_region_init_ram(), then as soon as the framebuffer is added
to the memory hierarchy, it will have logging enabled (or any
aliases of the framebuffer).
Still, I think we should
On 07/20/2011 03:10 AM, Avi Kivity wrote:
On 07/19/2011 11:51 PM, Anthony Liguori wrote:
On 07/19/2011 11:10 AM, Avi Kivity wrote:
On 07/19/2011 07:05 PM, Avi Kivity wrote:
On 07/19/2011 05:50 PM, Anthony Liguori wrote:
There's bits I don't like about the interface
Which bits are these?
On Wed, Jul 20, 2011 at 05:32:54PM +0300, Avi Kivity wrote:
On 07/20/2011 04:57 PM, Jan Kiszka wrote:
Something around dirty logging is still seriously borken: when I boot
with standard or cirrus vga, the screen is not properly updated in
logged modes.
I don't see this here, will retest.
On 2011-07-20 16:37, Michael S. Tsirkin wrote:
On Wed, Jul 20, 2011 at 05:32:54PM +0300, Avi Kivity wrote:
On 07/20/2011 04:57 PM, Jan Kiszka wrote:
Something around dirty logging is still seriously borken: when I boot
with standard or cirrus vga, the screen is not properly updated in
logged
On 2011-07-20 16:54, Avi Kivity wrote:
On 07/20/2011 05:37 PM, Michael S. Tsirkin wrote:
If you do a memory_region_set_log() immediately after
memory_region_init_ram(), then as soon as the framebuffer is added
to the memory hierarchy, it will have logging enabled (or any
aliases of the
On 07/20/2011 06:58 PM, Jan Kiszka wrote:
On 2011-07-20 16:54, Avi Kivity wrote:
On 07/20/2011 05:37 PM, Michael S. Tsirkin wrote:
If you do a memory_region_set_log() immediately after
memory_region_init_ram(), then as soon as the framebuffer is added
to the memory hierarchy, it will
On 07/20/2011 07:13 PM, Jan Kiszka wrote:
BTW, what's broken is legacy VGA mem dirty logging. Was simply dropped
during the conversion, and now I'm missing some links between vga core
and its users to reestablish it generically.
You mean logging of 0xa-0xc? That's probably a
On Wed, Jul 20, 2011 at 05:54:26PM +0300, Avi Kivity wrote:
On 07/20/2011 05:37 PM, Michael S. Tsirkin wrote:
If you do a memory_region_set_log() immediately after
memory_region_init_ram(), then as soon as the framebuffer is added
to the memory hierarchy, it will have logging enabled
On 07/20/2011 05:31 PM, Anthony Liguori wrote:
The VGA device doesn't know *if* it is mapped. It can be obstructed by
the chipset and by SMM. Other chipsets we emulate may support multiple
VGA cards.
The i440fx can support multiple VGA cards just fine.
Legacy region accesses are always
On 2011-07-20 18:02, Avi Kivity wrote:
On 07/20/2011 06:58 PM, Jan Kiszka wrote:
On 2011-07-20 16:54, Avi Kivity wrote:
On 07/20/2011 05:37 PM, Michael S. Tsirkin wrote:
If you do a memory_region_set_log() immediately after
memory_region_init_ram(), then as soon as the framebuffer is
On 07/17/2011 02:13 PM, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were converted,
except for eepro100.c, which uses the same MemoryRegionOps for both
portio and
On 07/20/2011 07:10 PM, Michael S. Tsirkin wrote:
and vga could do it if the vnc display
is disconnected, or if the update rate is so high it can just assume
all memory is dirty.
Yes, but it's not something *devices* should be doing.
No one knows about the frame buffer except the vga
On 07/17/2011 06:13 AM, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were converted,
except for eepro100.c, which uses the same MemoryRegionOps for both
portio and
On 07/19/2011 04:09 PM, Anthony Liguori wrote:
On 07/17/2011 06:13 AM, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were
converted,
except for eepro100.c, which
On 07/19/2011 04:56 PM, Michael S. Tsirkin wrote:
On Sun, Jul 17, 2011 at 02:13:27PM +0300, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were converted,
except
On Sun, Jul 17, 2011 at 02:13:27PM +0300, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were converted,
except for eepro100.c, which uses the same MemoryRegionOps for
On 07/19/2011 08:27 AM, Avi Kivity wrote:
On 07/19/2011 04:09 PM, Anthony Liguori wrote:
On 07/17/2011 06:13 AM, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were converted,
On 07/19/2011 05:50 PM, Anthony Liguori wrote:
There's bits I don't like about the interface
Which bits are these?
Nothing I haven't already commented on. I think there's too much in
the generic level. I don't think coalesced I/O belongs here. It's a
concept that doesn't fit. I
On 07/19/2011 07:05 PM, Avi Kivity wrote:
On 07/19/2011 05:50 PM, Anthony Liguori wrote:
There's bits I don't like about the interface
Which bits are these?
Nothing I haven't already commented on. I think there's too much in
the generic level. I don't think coalesced I/O belongs here.
On 2011-07-19 15:56, Michael S. Tsirkin wrote:
On Sun, Jul 17, 2011 at 02:13:27PM +0300, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were converted,
except for
On 2011-07-19 19:14, Avi Kivity wrote:
On 07/19/2011 08:01 PM, Jan Kiszka wrote:
On 2011-07-19 15:56, Michael S. Tsirkin wrote:
On Sun, Jul 17, 2011 at 02:13:27PM +0300, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
On 07/19/2011 08:01 PM, Jan Kiszka wrote:
On 2011-07-19 15:56, Michael S. Tsirkin wrote:
On Sun, Jul 17, 2011 at 02:13:27PM +0300, Avi Kivity wrote:
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new
On 07/19/2011 11:10 AM, Avi Kivity wrote:
On 07/19/2011 07:05 PM, Avi Kivity wrote:
On 07/19/2011 05:50 PM, Anthony Liguori wrote:
There's bits I don't like about the interface
Which bits are these?
Nothing I haven't already commented on. I think there's too much in
the generic level. I
On Tue, Jul 19, 2011 at 11:51 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 07/19/2011 11:10 AM, Avi Kivity wrote:
On 07/19/2011 07:05 PM, Avi Kivity wrote:
On 07/19/2011 05:50 PM, Anthony Liguori wrote:
There's bits I don't like about the interface
Which bits are these?
Nothing
On 07/19/2011 04:03 PM, Sasha Levin wrote:
On Tue, Jul 19, 2011 at 11:51 PM, Anthony Liguorianth...@codemonkey.ws wrote:
The e1000 is not performance competitive with virtio-net though so it
certainly is reasonable to assume that noone would notice if we removed
coalesced I/O from the e1000.
New in this version:
MemoryRegionOps gained .old_mmio and .old_portio members, which allow
reusing old-style callbacks with the new API. All uses were converted,
except for eepro100.c, which uses the same MemoryRegionOps for both
portio and mmio. Some intermediate patches do introduce
38 matches
Mail list logo
