WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] privcmd: MMAPBATCH: Fix error handling/reporting

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] privcmd: MMAPBATCH: Fix error handling/reporting
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 21 May 2009 10:14:51 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 21 May 2009 10:15:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1242895899.22654.92.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1242830676.22654.66.camel@xxxxxxxxxxxxxxxxxxxxxx> <1242830730-3341-1-git-send-email-ian.campbell@xxxxxxxxxx> <4A145B12.4050408@xxxxxxxx> <1242895899.22654.92.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Ian Campbell wrote:
The noise is just for debugging; if failure is expected, then maybe we can extend it to be quiet about those cases.

In this specific instance going directly at the mmu_udpate interface is
probably better since the propagation of errors from the multicall
infrastructure is tricky (well, currently non-existent). I don't think
multicalls would buy us anything here anyhow since mmu_update is batched
already.

Yeah. The generic multicall stuff is (should be) tuned for the common case of no errors. I think this is the first instance of something where we expect errors back. The multicall path is fairly hot, and I suspect it's going to need some trimming when the real performance work starts, so keeping it low-feature is a good idea.

(Though we could make use of maybe-fail to deal with vmap aliases in pte-pinning...)

This breaks compiling xenfs as a module; neither flush_tlb_all or arbitrary_virt_to_machine are exported, I think.

Rather than exporting those I think moving remap_domain_mfn_range() to
core code (with xen_ on the front of the name) and exporting that would
be cleaner. Thoughts?

Yes, seems reasonable to me. Though if its arch-neutral, drivers/xen would be better.

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel