qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Johannes Luber" <JALuber@gmx.de>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] tlb_update_dirty() question
Date: Tue, 15 Sep 2009 13:28:16 +0200	[thread overview]
Message-ID: <20090915112816.99190@gmx.net> (raw)
In-Reply-To: <f43fc5580909140914q70f55057y1623495297d0d831@mail.gmail.com>

> On Mon, Sep 14, 2009 at 12:00 PM, Johannes Luber <JALuber@gmx.de> wrote:
...
> >
> > The comment is particularly insightful. p is supposed to be a host
> pointer yet the initialization code uses "(unsigned long)" in a cast for an
> expression which has the type target_phys_addr_t because the struct variable
> "addend" has this type.
> 
> The addend is target_phys_addr_t type, because then we can get back to
> host address ranges on 32 bit host. Consider for example guest address
> at 8G backed by host memory at 1G: the addend is -7G.

Looking at

int tlb_set_page_exec(CPUState *env, target_ulong vaddr,
                      target_phys_addr_t paddr, int prot,
                      int mmu_idx, int is_softmmu)
{
}

(I assume that the only place addend is set), I see these two lines:

    addend = (unsigned long)qemu_get_ram_ptr(pd & TARGET_PAGE_MASK);
    ...
    te->addend = addend - vaddr;

Assuming target_ulong and unsigned long as 32-bit values (despite being on 64-bit system) I don't see how your example can work. There is no way to make addend bigger than (+/-)4G.

> 
> > This cast assumes that unsigned long is at least as big as
> target_phys_addr_t. Under Unix this may be true, but Windows C compilers treat long ==
> int and int remains a 32-bit type. Why isn't simply target_phys_addr_t used
> as cast? target_phys_addr_t does support max(target pointer size, host
> pointer size), doesn't it? Or is there another option?
> 
> No, the cast assumes that sum of guest addr and addend is a valid host
> address, which should be true. For memory, the resulting address is
> simply pointer to host memory. If any of the lowest bits of the sum
> are set, the area is MMIO.
> 
All in all, I take it that Qemu basically targets only Unix (the link to the Windows source version is merely a patch set). At least I know that my assumptions have been right and so I can fix these "(unsigned long)" places for myself.

Thanks for your time!
Johannes
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

      reply	other threads:[~2009-09-15 11:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-14  9:00 [Qemu-devel] tlb_update_dirty() question Johannes Luber
2009-09-14 16:14 ` Blue Swirl
2009-09-15 11:28   ` Johannes Luber [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090915112816.99190@gmx.net \
    --to=jaluber@gmx.de \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).