From: Scott Baker <YoshiHQ@Juno.com>
To: xen-devel@lists.xensource.com
Subject: Re: Logging External Page Writes for a Given Domain
Date: Tue, 21 Feb 2006 13:13:41 -0700 [thread overview]
Message-ID: <43FB7475.5050208@Juno.com> (raw)
In-Reply-To: <43F957B0.4090803@us.ibm.com>
Anthony,
Thanks for your response! I've been thinking more about exactly what
the requirements are, and it amounts to the following.
The end goal is to know the net result of any foreign-domain page writes
to all of a domain's (call it Domain P) pages. I don't actually need to
know the contents of every individual foreign write to Domain P's pages
per se, just which the contents of the pages that were modified by
foreign domains since Domain P was last run.
Let me give an example to illustrate. Domain P is running. It is then
suspended to allow another domain, Domain X, to start execution. Domain
X happens to have a few pages of Domain P mapped into its address
space. (This may be due to a device driver's page mapping from Domain
0, or just another Domain mapping -- I don't care why the pages are
mapped). Now, during its time slice, Domain X modifies (over a period
of several writes) two of Domain P's pages: page 19 and 94. Then,
Domain X is suspended and Domain Y is run. Domain Y also modifies
Domain P's page 94. Finally, Domain Y is suspended so Domain P can
resume. It is at this point, *just before Domain P resumes*, that I
would like to be able to have a list of the pages (if any) that have
been written by a foreign domain (94 and 19, in this example). With
that list, I would like to log the *entire contents* of those modified
pages of Domain P for my later use -- I don't need to know who wrote
what when, just which pages were modified so I can log their new contents.
So, in essence, *just before* every time that Domain P is allowed to
resume, I want to have a list of pages that have been modified *since
Domain P finished its previous time slice*, for the purpose of logging
the contents of each of those changed pages.
Having said all that, what is the most straightforward way to implement
this (it needn't be the most efficient, though gross inefficiency would
be nice to avoid)?
I really appreciate the feedback I've received.
Thanks again,
Scott
Anthony Liguori wrote:
> Scott Baker wrote:
>> Hello, all:
>>
>> My team's goal is to be able to log all writes that are made to any
>> memory page of a certain domain, except those writes that the domain
>> itself makes. That is to say, if Domain 2 is the domain we want to
>> log page writes for (where logging is capturing what was written and
>> its location), then we want to be able to log all the writes made by
>> any domain /except/ Domain 2 -- i.e., writes made to shared pages
>> that belong to Domain 2.
> The details here are going to make a big difference. Do you want to
> know the content of every write?
>
> You'll have to modify Xen. You can probably reuse some of the shadow
> paging code to track the dirty mappings of foreign pages for a
> domain. However, this won't track the contents of the write.
>
> If you want to do that, you're going to have to implement a large
> amount of emulation to track what data gets written to the page so you
> can emulate the writes completely. If this is an important
> requirement, you may wish to try to user an emulator (Bochs or qemu).
>
> Regards,
>
> Anthony Liguori
>>
>> Ideally, we would like to be able to have these writes for domain /x/
>> detected and trap to a process running on Domain 0, with minimal VMM
>> modification. Preferably, the method used would only cause
>> significant overhead when a write is made from outside domain /x/
>> (rather than for every write /x/ and everyone else makes), but I'm
>> not picky about efficiency at the moment.
>>
>> The rough idea we have at this point is to make the monitor process
>> on Domain 0 mark all the pages of Domain /x/ as read-only (while
>> remembering which are actually read-only). Then, when a write-fault
>> occurred, the VMM would pass it on to the monitoring process, which
>> would then let Domain /x/ finish the write, the monitor would record
>> what was written, and let everything continue as normal.
>>
>> Unfortunately, I'm not sure how that vague sketch fits into Xen. For
>> the page table read-only flag setting, would we use the
>> update_va_mapping() hypercall? And, how would the monitoring process
>> let Domain /x/ finish the write and then get control back? (Or, does
>> the VMM know what is about to be written, so we could just pass that
>> to the monitoring process?) Finally, where in Xen's code would we
>> have to go to modify the fault-handling behavior so the callback
>> could be made?
>>
>> Hope I'm clear, and hope you can help a newbie!
>>
>> Thanks,
>> Scott
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
next prev parent reply other threads:[~2006-02-21 20:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-19 7:31 Logging External Page Writes for a Given Domain Scott Baker
2006-02-20 5:46 ` Anthony Liguori
2006-02-21 20:13 ` Scott Baker [this message]
2006-02-21 20:17 ` Anthony Liguori
2006-02-21 20:40 ` Scott Baker
2006-02-28 0:09 ` Scott Baker
2006-02-28 0:17 ` Anthony Liguori
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=43FB7475.5050208@Juno.com \
--to=yoshihq@juno.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.