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

Re: [Xen-devel] Xc_mem_access_enable_emulate() is currently a no-operation

  • To: "Lengyel, Tamas" <tlengyel@xxxxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Mon, 7 Dec 2015 20:35:15 +0200
  • Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Mon, 07 Dec 2015 18:35:23 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=BA6d/WZaKXmuPEd0E6hk+c+38dXQTFpfHhNZmO4IneTNIPgGloALuKt5L5i7nV2JIUyYYC/ep1jam2Lye+eZP5bCXtyBN3Dvyf6HLM71sTz+mzT0UwsUh7a/tWBA99PeCiklApJstFoVfpO9XYo2kay/vxqjOmaRNE0fkygYTy8cjgqYxNF+SLnZ61wYWrm17daIICNbkXn7o4Lwtn9Nq1nrst+V/OhFBEAEWb31/kfFRo6IGsZApjTPiKEgMejPGgDarcLE05sacDLko2huidn1+3KIbJ7TG3HaxSC5DA5WzS28+oYg/efFUlkf5NYAxBpDyODEx6dqZNRuxB2CWA==; h=Received:Received:Received:Received:Received:Subject:To:References:Cc:From:X-Enigmail-Draft-Status:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 12/07/2015 07:55 PM, Lengyel, Tamas wrote:
> On Mon, Dec 7, 2015 at 4:09 AM, Razvan Cojocaru
> <rcojocaru@xxxxxxxxxxxxxxx <mailto:rcojocaru@xxxxxxxxxxxxxxx>> wrote:
>     Hello,
>     While looking at some code with Tamas these past few days, we discovered
>     that xc_mem_access_enable_emulate() doesn't actually do anything other
>     that setting the mem_access_emulate_enabled flag.
>     Fixing that would likely be trivial (if the flag is not set,
>     p2m_mem_access_emulate_check() should just return). However, my question
>     is: do we really need that function? Are there cases where it would make
>     sense to use the vm_event subsystem but disable emulation support? After
>     all, if the client code wants to use emulation support it can call
>     xc_mem_access_enable_emulate(), and if not it can simply not set the
>     EMULATE flags in the vm_event replies.
>     As far as I'm concerned, the libxc function can go (along with the
>     per-domain flag), but then again we're emulation-intensive so it's quite
>     possible that I'm not seeing the proper use case for this.
>     Thoughts?
> It may make sense to gate the allocation of struct arch_vm_event to only
> happen when emulation has been enabled beforehand for the domain (the
> struct is used only for this purpose). Most places where it is used its
> checked for by unlikely(v->arch.vm_event) checks anyway so I feel like
> this was the original intention of having this flag to begin with. It's
> not checked everywhere like this though so we need to verify that all
> places that use it do check before using it.

I think the vm_event cleanup series (which introduced
xc_mem_access_enable_emulate()) hit staging some months before I've
changed the code to dynamically allocate that struct.

Also, the struct is not only used for emulation. Please see the struct
monitor_write_data write_data; member, that regulates CR and MSR writes.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.