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 *devi
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 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 m
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 t
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 routed
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 loggi
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 prob
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 hierar
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
>>> a
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
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, wil
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 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 sh
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
cpu_register_physical_
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
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 pat
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 pat
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 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
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
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 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. Mo
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. I
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 ther
On 07/19/2011 04:03 PM, Sasha Levin wrote:
On Tue, Jul 19, 2011 at 11:51 PM, Anthony Liguori 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.
The point is, it's so
On Tue, Jul 19, 2011 at 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 th
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 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 n
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 al
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 fo
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 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 think
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,
ex
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 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 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 uses
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 m
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 dis
38 matches
Mail list logo
