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
prev parent 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).