From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] vm_event: make sure the domain is paused in key domctls
Date: Fri, 29 Jan 2016 08:52:45 +0200 [thread overview]
Message-ID: <56AB0C3D.1010001@bitdefender.com> (raw)
In-Reply-To: <CABfawhmmKoHGsh0sCpsS4TJ_uz9ZVT+7sfiOX19uOZz3Qsv7Vg@mail.gmail.com>
On 01/28/2016 11:47 PM, Tamas K Lengyel wrote:
>
>
> On Thu, Jan 28, 2016 at 2:05 PM, Razvan Cojocaru
> <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>> wrote:
>
> On 01/28/2016 10:09 PM, Tamas K Lengyel wrote:
> > On Thu, Jan 28, 2016 at 6:52 AM, Razvan Cojocaru
> > <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>
> <mailto:rcojocaru@bitdefender.com
> <mailto:rcojocaru@bitdefender.com>>> wrote:
> >
> > This patch pauses the domain for all writes through the 'ad'
> > pointer in monitor_domctl(), defers a domain_unpause() call until
> > after the CRs are updated for the MONITOR_EVENT_WRITE_CTRLREG
> > case, and makes sure that the domain is paused for both vm_event
> > enable and disable cases in vm_event_domctl().
> > Thanks go to Andrew Cooper for his review and suggestions.
> >
> >
> > For vm_event_enable the domain is already paused by libxc before the
> > domctl is issued. I don't see a problem in doing another pause in Xen,
> > but given we have XSA-99, just doing this pause in Xen would not be
> > enough. So is it really necessary/fixes anything?
>
> This isn't about XSA-99, the problem here is related to my previous
> patch "x86 vm_event: reset monitor in vm_event_cleanup_domain()". While
> that improves matters and greatly reduces the chances of crashes due to
> hvm_msr_write_intercept() or hvm_set_crX() dereferencing a NULL
> v->arch.vm_event that's assumed to be OK, when the corresponding
> v->domain->arch.monitor is non-zero, the foolproof way is to make sure
> that functions such as vm_event_cleanup_domain() are always being called
> only while the domain has been paused. So there should be a
> domain_pause() call somewhere on the call path before that.
>
>
> Sure, but that's the disable case. I was only wondering about the enable
> case where the domain is already paused.
Yes, for the disable case it is functionally redundant. I just thought
it would be consistent to use domain_pause() throughout and didn't think
it would hurt anything. But I have nothing against removing the
domain_pause() for the enable case (perhaps replacing it with a comment
that libxc already pauses externally), unless Andrew has any objections.
Thanks,
Razvan
next prev parent reply other threads:[~2016-01-29 6:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 13:52 [PATCH] vm_event: make sure the domain is paused in key domctls Razvan Cojocaru
2016-01-28 14:10 ` Andrew Cooper
2016-01-28 14:27 ` Razvan Cojocaru
2016-01-28 14:52 ` Razvan Cojocaru
2016-01-28 20:09 ` Tamas K Lengyel
2016-01-28 21:05 ` Razvan Cojocaru
2016-01-28 21:47 ` Tamas K Lengyel
2016-01-29 6:52 ` Razvan Cojocaru [this message]
2016-01-29 6:55 ` Razvan Cojocaru
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=56AB0C3D.1010001@bitdefender.com \
--to=rcojocaru@bitdefender.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=tamas@tklengyel.com \
--cc=xen-devel@lists.xen.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 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.