qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] vga optmization


From: Glauber Costa
Subject: Re: [Qemu-devel] vga optmization
Date: Mon, 3 Nov 2008 16:47:54 -0200

On Mon, Nov 3, 2008 at 4:41 PM, Blue Swirl <address@hidden> wrote:
> On 11/3/08, Glauber Costa <address@hidden> wrote:
>> On Mon, Nov 3, 2008 at 4:03 PM, Blue Swirl <address@hidden> wrote:
>>  > On 11/3/08, Glauber Costa <address@hidden> wrote:
>>  >> Hi guys,
>>  >>
>>  >>  this is a port of current kvm vga memory optimization to our new
>>  >>  infrastructure proposed by anthony. It's goal is to use as few
>>  >>  kvm specific hooks as possible. In fact, the only one I'm relying
>>  >>  on is enabling/disabling of logging. The rest, is pretty much general.
>>  >>
>>  >>  We map the linear frame buffer area as RAM, and then use dirty tracking
>>  >>  to decide whether or not to update it. To be consistent with qemu,
>>  >>  this version, differently from upstream kvm, tracks memory based on its
>>  >>  physical address, represented by vram_offset, instead of vram_ptr, or
>>  >>  any other construct.
>>  >>
>>  >>  Let me know what you think
>>  >
>>  > The patch does not apply, because of the kvm files. What patches do I
>>  > need to apply first? I'd like to see how does the optimization apply
>>  > to TCX.
>>
>>
>> Yes, you are missing kvm patches some time ago, which he plans to merge.
>>
>>
>>  > This also may mean that some of my comments below can be invalid.
>>  >
>>  >>  +void set_vram_mapping(target_phys_addr_t begin, target_phys_addr_t 
>> end, ram_addr_t target)
>>  >
>>  > No "static"?
>>
>> thanks, will update.
>>
>>
>>  >
>>  >>  +{
>>  >>  +    /* align begin and end address */
>>  >>  +    begin = begin & TARGET_PAGE_MASK;
>>  >>  +    end = begin + VGA_RAM_SIZE;
>>  >>  +    end = (end + TARGET_PAGE_SIZE -1 ) & TARGET_PAGE_MASK;
>>  >
>>  > This will fail if "end" is at the last page of the memory.
>>
>>
>> How so? I don't think it's possible for the addr 0xsomething0001 to be
>>  valid, but 0x(something+1)000 to be not.
>
> 0xfffff001 + 0xfff = 0 (wrapped), then masking still gives 0.

oh, you're talking about the last page in the possible address space.
In that case I agree, but I believe we're not expecting vga to ever be there.

>
>>  >
>>  >>  +    uint32_t vga_io_memory;                                            
>>  \
>>  >
>>  > cpu_register_io_memory() returns an "int".
>>
>>
>> can it possibly be negative?
>>  that said, of course I can change it for consistency, but I'd like to
>>  understand it more
>
> In case of error it could be negative but I'm only thinking about consistency.
fair. I'll update it.
>
>



-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]