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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] privcmd: MMAPBATCH: Fix error handling/reporting
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Thu, 21 May 2009 09:51:39 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 21 May 2009 01:52:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A145B12.4050408@xxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <1242830676.22654.66.camel@xxxxxxxxxxxxxxxxxxxxxx> <1242830730-3341-1-git-send-email-ian.campbell@xxxxxxxxxx> <4A145B12.4050408@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2009-05-20 at 15:33 -0400, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > On error IOCTL_PRIVCMD_MMAPBATCH is expected to set the top nibble of
> > the effected MFN and return 0. Currently it leaves the MFN unmodified
> > and returns the number of failures. Therefore:
> >
> > - reimplement remap_domain_mfn_range() using direct
> >   HYPERVISOR_mmu_update() calls and small batches. The xen_set_domain_pte()
> >   interface does not report errors and since some failures are
> >   expected/normal using the multicall infrastructure is too noisy.
> >   
> 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.

On Wed, 2009-05-20 at 17:13 -0400, Jeremy Fitzhardinge wrote:
> 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?

Ian.



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