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

Re: [Xen-devel] [PATCH v2 09/12] x86/altp2m: add remaining support routines.


  • To: "Lengyel, Tamas" <tlengyel@xxxxxxxxxxx>, Ed White <edmund.h.white@xxxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Thu, 25 Jun 2015 16:40:33 +0300
  • Cc: Ravi Sahita <ravi.sahita@xxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Thu, 25 Jun 2015 13:40:26 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=HtlSg81cmU595LAIvJNVkP4W/cCvGDKHsdW7pwiP6Wmu7zES6Bmsc6a4ga8WD1zX5NwcsOsvRMtQwPH34R/cfJ5ogQua6YYuthXFNLSzlaJ07L2wVL6R5jP3JJGX+yR8M1f1RKyeveNz+K00S7pdtBGuf+abTZvXUnNe5WwIh2yixjmscNBEz3XBlLRstVBs/xlfR094Vdvc6RJOLDZWy9/psD4Jxq6Dtc0MUVya4SZ5XSzpdQhS0mR8Z7KlACPaeh69EXaJtWcuy3C4p0xLhkLIrg6x+aoLIcKwGcToXaqwrYLYOG+rVkHrOs1EhMkdDALU0YoG7tilFyu3ft8syw==; 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 06/25/2015 03:44 PM, Lengyel, Tamas wrote:
> On Wed, Jun 24, 2015 at 2:06 PM, Ed White <edmund.h.white@xxxxxxxxx
> <mailto:edmund.h.white@xxxxxxxxx>> wrote:
>     On 06/24/2015 09:15 AM, Lengyel, Tamas wrote:
>     >> +bool_t p2m_set_altp2m_mem_access(struct domain *d, uint16_t idx,
>     >> +                                 unsigned long pfn, xenmem_access_t
>     >> access)
>     >> +{
>     >>
>     >
>     > This function IMHO should be merged with p2m_set_mem_access and should 
> be
>     > triggerable with the same memop (XENMEM_access_op) hypercall instead of
>     > introducing a new hvmop one.
> 
>     I think we should vote on this. My view is that it makes
>     XENMEM_access_op
>     too complicated to use.
> 
> The two functions are not very long and share enough code that it would
> justify merging. The only big change added is the copy from host->alt
> when the entry doesn't exists in alt, and that itself is pretty self
> contained. Let's see if we can get a third opinion on it..

At first sight (I admit I'm rather late in the game and haven't had a
chance to follow the series closely from the beginning), the two
functions do seem to be mergeable (or at least the common code factored
out in static helper functions).

Also, if Ed's concern is that the libxc API would look unnatural if
xc_set_mem_access() is used for both purposes, as far as I can tell the
only difference could be a non-zero last altp2m parameter, so I agree
with you that the less functions doing almost the same thing the better
(I have been guilty of this in the past too, for example with my
xc_enable_introspection() function ;) ).

So I'd say, yes, if possible merge them.


Regards,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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