Re: [Xen-devel] how to enable kdb for xen
The version embedded with kdb only updates to 4.1.0. How can I use it with xen 4.6? Or is there any other debuggers which can step in Xen? From: quizy_jo...@outlook.com To: xen-devel@lists.xen.org Date: Wed, 16 Dec 2015 06:57:02 + Subject: [Xen-devel] how to enable kdb for xen I tried to debug xen use kdb. After compiling xen with debug=y, is there any further steps I should take? I can get console outputs start with:Xen 4.4.1(XEN) Xen version 4.4.1 (root@) (gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4) debug=y Wed Dec 16 11:01:14.But I can't step into the boot procedure. The kdb seems not built in and there is no kdb folder in /tools/debugger. How can I build xen-4.4.1/xen-4.4.6 with kdb? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] VT-d: Fix vt-d flush timeout issue.
>>> On 16.12.15 at 04:51, wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1318,6 +1318,25 @@ int iommu_remove_device(struct pci_dev *pdev)
> return hd->platform_ops->remove_device(pdev->devfn, pci_to_dev(pdev));
> }
>
> +int iommu_hide_device(struct pci_dev *pdev)
> +{
> +if ( !pdev || !pdev->domain )
> +return -EINVAL;
> +
> +spin_lock(&pcidevs_lock);
> +pdev->domain = dom_xen;
> +list_add(&pdev->domain_list, &dom_xen->arch.pdev_list);
> +spin_unlock(&pcidevs_lock);
> +
> +return 0;
> +}
This is effectively a copy of pci_hide_device(), and is misnamed (since
it takes a PCI device as argument). I do not see why you shouldn't be
able to use pci_hide_device() after removing its __init annotation or
a suitably named wrapper around _pci_hide_device(). Not specifically
that the way you do this right now you corrupt the original owning
domain's PCI device list - you need to remove the device from that
list before adding it to dom_xen's (which then will naturally entail
clearing ->domain, at once satisfying _pci_hide_device()'s early
check, which is there for the very reason of ensuring not to corrupt
any list).
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1890,6 +1890,9 @@ static int intel_iommu_add_device(u8 devfn, struct
> pci_dev *pdev)
> if ( !pdev->domain )
> return -EINVAL;
>
> +if ( pdev->domain == dom_xen )
> +return -EACCES;
I'm not sure about the need for this check, ...
> @@ -2301,6 +2304,9 @@ static int intel_iommu_assign_device(
> if ( list_empty(&acpi_drhd_units) )
> return -ENODEV;
>
> +if ( pdev->domain == dom_xen )
> +return -EACCES;
... and I clearly don't see the need for this one. Please explain,
keeping in mind that generic IOMMU code should be enforcing things
like this (and at least in the assign case should already be doing so).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V3 PATCH 7/9] x86/hvm: pkeys, add pkeys support for guest_walk_tables
On Tue, 2015-12-15 at 02:02 -0700, Jan Beulich wrote:
> > > > On 15.12.15 at 09:14, wrote:
> > On Fri, 2015-12-11 at 02:26 -0700, Jan Beulich wrote:
> > > > > > On 10.12.15 at 19:19, wrote:
> > > > On 07/12/15 09:16, Huaitong Han wrote:
> > > > > +if ( likely(!pte_pkeys) )
> > > > > +return 0;
> > > > > +
> > > > > +/* Update vcpu xsave area */
> > > > > +fpu_xsave(vcpu);
> > > >
> > > > Is there a reason you're calling fpu_xsave() directly here,
> > > > rather
> > > > than
> > > > just calling vcpu_save_fpu()? That saves you actually doing
> > > > the
> > > > xsave
> > > > if the fpu hasn't been modified since the last time you read
> > > > it.
> > >
> > > I've already said on an earlier version that wholesale saving of
> > > the
> > > entire XSAVE state is wrong here. It should just be the single
> > > piece
> > > that we're actually interested in, and it quite likely shouldn't
> > > go
> > > into
> > > struct vcpu (but e.g. into a local buffer).
> >
> > The comments on V2 version said using vcpu_save_fpu is wrong
> > because of
> > v->fpu_dirtied, but why wholesale saving of the entire XSAVE state
> > is
> > wrong here? I understand xsave maybe cost a little more.
>
> "A little" is quite a bit of an understatement.
>
> > But if we just
> > save the single piece, many functions are not reused because
> > xstate_comp_offsets is pointless, and we need add a new function as
> > follow that looks not good:
>
> Well, I wouldn't want you to introduce a brand new function, but
> instead just factor out the necessary piece from xsave() (making
> the new one take a struct xsave_struct * instead of a struct vcpu *,
> and calling it from what is now xsave()).
So the function looks like this:
unsigned int get_xsave_pkru(struct vcpu *v)
{
void *offset;
struct xsave_struct *xsave_area;
uint64_t mask = XSTATE_PKRU;
unsigned int index = fls64(mask) - 1;
unsigned int pkru = 0;
if ( !cpu_has_xsave )
return 0;
BUG_ON(xsave_cntxt_size < XSTATE_AREA_MIN_SIZE);
xsave_area = _xzalloc(xsave_cntxt_size, 64);
if ( xsave_area == NULL )
return 0;
xsave(xsave_area, mask);
offset = (void *)xsave_area + (xsave_area_compressed(xsave) ?
XSTATE_AREA_MIN_SIZE : xstate_offsets[index] );
memcpy(&pkru, offset, sizeof(pkru));
xfree(xsave_area);
return pkru;
}
>
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V3 PATCH 7/9] x86/hvm: pkeys, add pkeys support for guest_walk_tables
>>> On 16.12.15 at 09:16, wrote:
> On Tue, 2015-12-15 at 02:02 -0700, Jan Beulich wrote:
>> Well, I wouldn't want you to introduce a brand new function, but
>> instead just factor out the necessary piece from xsave() (making
>> the new one take a struct xsave_struct * instead of a struct vcpu *,
>> and calling it from what is now xsave()).
> So the function looks like this:
> unsigned int get_xsave_pkru(struct vcpu *v)
> {
> void *offset;
> struct xsave_struct *xsave_area;
> uint64_t mask = XSTATE_PKRU;
> unsigned int index = fls64(mask) - 1;
> unsigned int pkru = 0;
>
> if ( !cpu_has_xsave )
> return 0;
>
> BUG_ON(xsave_cntxt_size < XSTATE_AREA_MIN_SIZE);
> xsave_area = _xzalloc(xsave_cntxt_size, 64);
> if ( xsave_area == NULL )
> return 0;
>
> xsave(xsave_area, mask);
> offset = (void *)xsave_area + (xsave_area_compressed(xsave) ?
> XSTATE_AREA_MIN_SIZE : xstate_offsets[index] );
> memcpy(&pkru, offset, sizeof(pkru));
>
> xfree(xsave_area);
>
> return pkru;
> }
Depending on how frequently this might get called, the allocation
overhead may not be tolerable. I.e. you may want to set up e.g.
a per-CPU buffer up front. Or you check whether using RDPKRU
(with temporarily setting CR4.PKE) is cheaper than what you
do right now.
Also I don't think the buffer needs to be xsave_cntxt_size in size;
xstate_offsets[index] + sizeof(pkru) (and its equivalent in the
non-compressed case) should suffice.
And finally I don't think returning 0 in the allocation failure case
would be valid, as that - iiuc - means no restrictions at all, and
hence would hamper security inside the guest. But that's of
course moot if the allocation gets moved out of here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 38516: regressions - FAIL
This run is configured for baseline tests only. flight 38516 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38516/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 38503 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 38503 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-installfail blocked in 38503 test-amd64-amd64-xl-xsm 21 guest-start/debian.repeatfail like 38503 test-amd64-amd64-xl 21 guest-start/debian.repeatfail like 38503 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass version targeted for testing: qemuuf05b42d3fd30bb9673cc1ac1ee8c2af8f669964e baseline version: qemuua3154ccabcb21ac4e42877c965df60976832dbc5 Last test of basis38503 2015-12-12 01:55:40 Z4 days Testing same since38516 2015-12-14 18:57:09 Z1 days1 attempts People who touched revisions under test: Alex Zuepke Dr. David Alan Gilbert Kevin Wolf Markus Armbruster Max Reitz Peter Maydell jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl fail test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
Re: [Xen-devel] [V3 PATCH 7/9] x86/hvm: pkeys, add pkeys support for guest_walk_tables
On Wed, 2015-12-16 at 01:32 -0700, Jan Beulich wrote:
> > > > On 16.12.15 at 09:16, wrote:
> > On Tue, 2015-12-15 at 02:02 -0700, Jan Beulich wrote:
> > > Well, I wouldn't want you to introduce a brand new function, but
> > > instead just factor out the necessary piece from xsave() (making
> > > the new one take a struct xsave_struct * instead of a struct vcpu
> > > *,
> > > and calling it from what is now xsave()).
> > So the function looks like this:
> > unsigned int get_xsave_pkru(struct vcpu *v)
> > {
> > void *offset;
> > struct xsave_struct *xsave_area;
> > uint64_t mask = XSTATE_PKRU;
> > unsigned int index = fls64(mask) - 1;
> > unsigned int pkru = 0;
> >
> > if ( !cpu_has_xsave )
> > return 0;
> >
> > BUG_ON(xsave_cntxt_size < XSTATE_AREA_MIN_SIZE);
> > xsave_area = _xzalloc(xsave_cntxt_size, 64);
> > if ( xsave_area == NULL )
> > return 0;
> >
> > xsave(xsave_area, mask);
> > offset = (void *)xsave_area + (xsave_area_compressed(xsave) ?
> > XSTATE_AREA_MIN_SIZE : xstate_offsets[index] );
> > memcpy(&pkru, offset, sizeof(pkru));
> >
> > xfree(xsave_area);
> >
> > return pkru;
> > }
>
> Depending on how frequently this might get called, the allocation
> overhead may not be tolerable. I.e. you may want to set up e.g.
> a per-CPU buffer up front. Or you check whether using RDPKRU
> (with temporarily setting CR4.PKE) is cheaper than what you
> do right now.
RDPKRU does cost less than the function, and if temporarily setting
CR4.PKE is accepted, I will use RDPKRU instead of the function.
Andrew, what is your opinion?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/PCI: Intercept Dom0 MMCFG from dom0s in HVM containers
>>> On 15.12.15 at 22:02, wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1778,6 +1778,28 @@ int hvm_emulate_one_no_write(
> return _hvm_emulate_one(hvmemul_ctxt, &hvm_emulate_ops_no_write);
> }
>
> +static const struct x86_emulate_ops hvm_emulate_ops_mmio = {
> +.read = mmio_ro_emulated_read,
> +.insn_fetch = hvmemul_insn_fetch,
> +.write = mmio_intercept_write,
> +};
Blank line missing here, but as a probably better alternative this could
move into the function below.
> +int hvm_emulate_one_mmio(unsigned seg, unsigned bdf, unsigned long gla)
Name and function parameters don't match up (also for e.g. the
changed struct mmio_ro_emulate_ctxt). DYM e.g.
hvm_emulate_one_mmcfg()? (The function naming in x86/mm.c
is actually using mmio because its serving wider purpose than
just MMCFG write interception. Which makes me wonder whether
we don't actually need that other part for PVH too, in which case
the naming would again be fine.)
> +{
> +struct mmio_ro_emulate_ctxt mmio_ro_ctxt = {
> +.cr2 = gla,
> +.seg = seg,
> +.bdf = bdf
> +};
> +struct hvm_emulate_ctxt ctxt = { .ctxt.data = &mmio_ro_ctxt };
hvm_mem_access_emulate_one() so far is the only example pre-
initializing ctxt before calling hvm_emulate_prepare(), and I don't
think it actually needs this. I think the proper place to set .data is
after the call to hvm_emulate_prepare().
> +int rc;
> +
> +hvm_emulate_prepare(&ctxt, guest_cpu_user_regs());
> +rc = _hvm_emulate_one(&ctxt, &hvm_emulate_ops_mmio);
> +hvm_emulate_writeback(&ctxt);
Is this correct to be done unconditionally (i.e. regardless of rc)?
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3116,6 +3116,21 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
> long gla,
> goto out_put_gfn;
> }
>
> +if ( (p2mt == p2m_mmio_direct) && is_hardware_domain(currd) )
The PV condition includes a PFEC_page_present check, and I think
an equivalent should be added here too.
> +{
> +unsigned int seg, bdf;
> +const unsigned long *ro_map;
> +
> +if ( pci_mmcfg_decode(mfn_x(mfn), &seg, &bdf) &&
> + ((ro_map = pci_get_ro_map(seg)) == NULL ||
> + !test_bit(bdf, ro_map)) )
> +if (hvm_emulate_one_mmio(seg, bdf, gla) == X86EMUL_OKAY)
Two immediately adjacent if()-s should be folded into one.
> @@ -5266,8 +5260,8 @@ static int mmio_ro_emulated_write(
> unsigned int bytes,
> struct x86_emulate_ctxt *ctxt)
> {
> -struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
> -container_of(ctxt, struct mmio_ro_emulate_ctxt, ctxt);
> +struct mmio_ro_emulate_ctxt *mmio_ro_ctxt =
> +(struct mmio_ro_emulate_ctxt *)ctxt->data;
Pointless cast.
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -430,6 +430,9 @@ struct x86_emulate_ctxt
> } flags;
> uint8_t byte;
> } retire;
> +
> +/* Caller data that can be used by x86_emulate_ops */
There seems to be more missing in this comment than just the full
stop: x86_emulate_ops is a structure and hence can't use any
data.
> --- a/xen/include/asm-x86/hvm/emulate.h
> +++ b/xen/include/asm-x86/hvm/emulate.h
> @@ -57,6 +57,10 @@ void hvm_emulate_writeback(
> struct segment_register *hvmemul_get_seg_reg(
> enum x86_segment seg,
> struct hvm_emulate_ctxt *hvmemul_ctxt);
> +int hvm_emulate_one_mmio(
> +unsigned seg,
> +unsigned bdf,
Please don't omit the "int" here (and elsewhere whenever the
context doesn't suggest it's common practice in the given piece of
code).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V3 PATCH 7/9] x86/hvm: pkeys, add pkeys support for guest_walk_tables
>>> On 16.12.15 at 10:03, wrote:
> On Wed, 2015-12-16 at 01:32 -0700, Jan Beulich wrote:
>> > > > On 16.12.15 at 09:16, wrote:
>> > On Tue, 2015-12-15 at 02:02 -0700, Jan Beulich wrote:
>> > > Well, I wouldn't want you to introduce a brand new function, but
>> > > instead just factor out the necessary piece from xsave() (making
>> > > the new one take a struct xsave_struct * instead of a struct vcpu
>> > > *,
>> > > and calling it from what is now xsave()).
>> > So the function looks like this:
>> > unsigned int get_xsave_pkru(struct vcpu *v)
>> > {
>> > void *offset;
>> > struct xsave_struct *xsave_area;
>> > uint64_t mask = XSTATE_PKRU;
>> > unsigned int index = fls64(mask) - 1;
>> > unsigned int pkru = 0;
>> >
>> > if ( !cpu_has_xsave )
>> > return 0;
>> >
>> > BUG_ON(xsave_cntxt_size < XSTATE_AREA_MIN_SIZE);
>> > xsave_area = _xzalloc(xsave_cntxt_size, 64);
>> > if ( xsave_area == NULL )
>> > return 0;
>> >
>> > xsave(xsave_area, mask);
>> > offset = (void *)xsave_area + (xsave_area_compressed(xsave) ?
>> > XSTATE_AREA_MIN_SIZE : xstate_offsets[index] );
>> > memcpy(&pkru, offset, sizeof(pkru));
>> >
>> > xfree(xsave_area);
>> >
>> > return pkru;
>> > }
>>
>> Depending on how frequently this might get called, the allocation
>> overhead may not be tolerable. I.e. you may want to set up e.g.
>> a per-CPU buffer up front. Or you check whether using RDPKRU
>> (with temporarily setting CR4.PKE) is cheaper than what you
>> do right now.
> RDPKRU does cost less than the function, and if temporarily setting
> CR4.PKE is accepted, I will use RDPKRU instead of the function.
The question isn't just the RDPKRU cost, but that of the two CR4
writes.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 0/4] support linear p2m list in migrate stream v2
Add support for the virtual mapped linear p2m list of pv-domains in the v2 migrate stream. This will allow to migrate domains larger than 512 GB. Tested with 32- and 64-bit pv-domains both with and without linear p2m list and with a hvm domain. Changes in V3: - Moved defines to header file in patch 2 as requested by Andrew Cooper Changes in V2: - Added some sanity tests in patch 2 as suggested by Andrew Cooper - Modified patch 3 according to Andrew Cooper's requests: rename of check_iteration to check_vm_state, call check_vm_state after each checkpoint, don't change check_vm_state hook but do the check decision internally - Modified docs/features/migration.pandoc according to changes done in the series in patch 4 (requested by Andrew Cooper) Juergen Gross (4): libxc: split mapping p2m leaves into a separate function libxc: support of linear p2m list for migration of pv-domains libxc: stop migration in case of p2m list structural changes libxc: set flag for support of linear p2m list in domain builder docs/features/migration.pandoc| 7 +- tools/libxc/xc_dom_compat_linux.c | 2 +- tools/libxc/xc_dom_core.c | 2 + tools/libxc/xc_sr_common.h| 12 ++ tools/libxc/xc_sr_common_x86_pv.h | 7 + tools/libxc/xc_sr_save.c | 7 +- tools/libxc/xc_sr_save_x86_hvm.c | 7 + tools/libxc/xc_sr_save_x86_pv.c | 304 +- 8 files changed, 304 insertions(+), 44 deletions(-) -- 2.6.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 1/4] libxc: split mapping p2m leaves into a separate function
In order to prepare using the virtual mapped linear p2m list for
migration split mapping of the p2m leaf pages into a separate function.
Signed-off-by: Juergen Gross
Reviewed-by: Andrew Cooper
---
tools/libxc/xc_sr_save_x86_pv.c | 77 -
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index c8d6f0b..d7acd37 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -68,6 +68,50 @@ static int copy_mfns_from_guest(const struct xc_sr_context
*ctx,
}
/*
+ * Map the p2m leave pages and build an array of their pfns.
+ */
+static int map_p2m_leaves(struct xc_sr_context *ctx, xen_pfn_t *mfns,
+ size_t n_mfns)
+{
+xc_interface *xch = ctx->xch;
+unsigned x;
+
+ctx->x86_pv.p2m = xc_map_foreign_pages(xch, ctx->domid, PROT_READ,
+ mfns, n_mfns);
+if ( !ctx->x86_pv.p2m )
+{
+PERROR("Failed to map p2m frames");
+return -1;
+}
+
+ctx->save.p2m_size = ctx->x86_pv.max_pfn + 1;
+ctx->x86_pv.p2m_frames = n_mfns;
+ctx->x86_pv.p2m_pfns = malloc(n_mfns * sizeof(*mfns));
+if ( !ctx->x86_pv.p2m_pfns )
+{
+ERROR("Cannot allocate %zu bytes for p2m pfns list",
+ n_mfns * sizeof(*mfns));
+return -1;
+}
+
+/* Convert leaf frames from mfns to pfns. */
+for ( x = 0; x < n_mfns; ++x )
+{
+if ( !mfn_in_pseudophysmap(ctx, mfns[x]) )
+{
+ERROR("Bad mfn in p2m_frame_list[%u]", x);
+dump_bad_pseudophysmap_entry(ctx, mfns[x]);
+errno = ERANGE;
+return -1;
+}
+
+ctx->x86_pv.p2m_pfns[x] = mfn_to_pfn(ctx, mfns[x]);
+}
+
+return 0;
+}
+
+/*
* Walk the guests frame list list and frame list to identify and map the
* frames making up the guests p2m table. Construct a list of pfns making up
* the table.
@@ -173,7 +217,6 @@ static int map_p2m(struct xc_sr_context *ctx)
ctx->x86_pv.p2m_frames = (ctx->x86_pv.max_pfn + fpp) / fpp;
DPRINTF("max_pfn %#lx, p2m_frames %d", ctx->x86_pv.max_pfn,
ctx->x86_pv.p2m_frames);
-ctx->save.p2m_size = ctx->x86_pv.max_pfn + 1;
fl_entries = (ctx->x86_pv.max_pfn / fpp) + 1;
/* Map the guest mid p2m frames. */
@@ -211,38 +254,8 @@ static int map_p2m(struct xc_sr_context *ctx)
}
/* Map the p2m leaves themselves. */
-ctx->x86_pv.p2m = xc_map_foreign_pages(xch, ctx->domid, PROT_READ,
- local_fl, fl_entries);
-if ( !ctx->x86_pv.p2m )
-{
-PERROR("Failed to map p2m frames");
-goto err;
-}
+rc = map_p2m_leaves(ctx, local_fl, fl_entries);
-ctx->x86_pv.p2m_frames = fl_entries;
-ctx->x86_pv.p2m_pfns = malloc(local_fl_size);
-if ( !ctx->x86_pv.p2m_pfns )
-{
-ERROR("Cannot allocate %zu bytes for p2m pfns list",
- local_fl_size);
-goto err;
-}
-
-/* Convert leaf frames from mfns to pfns. */
-for ( x = 0; x < fl_entries; ++x )
-{
-if ( !mfn_in_pseudophysmap(ctx, local_fl[x]) )
-{
-ERROR("Bad mfn in p2m_frame_list[%u]", x);
-dump_bad_pseudophysmap_entry(ctx, local_fl[x]);
-errno = ERANGE;
-goto err;
-}
-
-ctx->x86_pv.p2m_pfns[x] = mfn_to_pfn(ctx, local_fl[x]);
-}
-
-rc = 0;
err:
free(local_fl);
--
2.6.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/4] libxc: support of linear p2m list for migration of pv-domains
In order to be able to migrate pv-domains with more than 512 GB of RAM
the p2m information can be specified by the guest kernel via a virtual
mapped linear p2m list instead of a 3 level tree.
Add support for this new p2m format in libxc.
As the sanity checking of the virtual p2m address needs defines for the
xen regions use those defines when doing page table checks as well.
Signed-off-by: Juergen Gross
Reviewed-by: Andrew Cooper
---
tools/libxc/xc_sr_common_x86_pv.h | 7 ++
tools/libxc/xc_sr_save_x86_pv.c | 194 +++---
2 files changed, 188 insertions(+), 13 deletions(-)
diff --git a/tools/libxc/xc_sr_common_x86_pv.h
b/tools/libxc/xc_sr_common_x86_pv.h
index 3234944..f80c753 100644
--- a/tools/libxc/xc_sr_common_x86_pv.h
+++ b/tools/libxc/xc_sr_common_x86_pv.h
@@ -3,6 +3,13 @@
#include "xc_sr_common_x86.h"
+/* Virtual address ranges reserved for hypervisor. */
+#define HYPERVISOR_VIRT_START_X86_64 0x8000ULL
+#define HYPERVISOR_VIRT_END_X86_64 0x87FFULL
+
+#define HYPERVISOR_VIRT_START_X86_32 0xF580ULL
+#define HYPERVISOR_VIRT_END_X86_32 0xULL
+
/*
* Convert an mfn to a pfn, given Xen's m2p table.
*
diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index d7acd37..40aa655 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -3,6 +3,12 @@
#include "xc_sr_common_x86_pv.h"
+/* Check a 64 bit virtual address for being canonical. */
+static inline bool is_canonical_address(xen_vaddr_t vaddr)
+{
+return ((int64_t)vaddr >> 47) == ((int64_t)vaddr >> 63);
+}
+
/*
* Maps the guests shared info page.
*/
@@ -116,7 +122,7 @@ static int map_p2m_leaves(struct xc_sr_context *ctx,
xen_pfn_t *mfns,
* frames making up the guests p2m table. Construct a list of pfns making up
* the table.
*/
-static int map_p2m(struct xc_sr_context *ctx)
+static int map_p2m_tree(struct xc_sr_context *ctx)
{
/* Terminology:
*
@@ -138,8 +144,6 @@ static int map_p2m(struct xc_sr_context *ctx)
void *guest_fl = NULL;
size_t local_fl_size;
-ctx->x86_pv.max_pfn = GET_FIELD(ctx->x86_pv.shinfo, arch.max_pfn,
-ctx->x86_pv.width) - 1;
fpp = PAGE_SIZE / ctx->x86_pv.width;
fll_entries = (ctx->x86_pv.max_pfn / (fpp * fpp)) + 1;
if ( fll_entries > fpp )
@@ -270,6 +274,170 @@ err:
}
/*
+ * Map the guest p2m frames specified via a cr3 value, a virtual address, and
+ * the maximum pfn. PTE entries are 64 bits vor both, 32 and 64 bit guests as
+ * in 32 bit case we support PAE guests only.
+ */
+static int map_p2m_list(struct xc_sr_context *ctx, uint64_t p2m_cr3)
+{
+xc_interface *xch = ctx->xch;
+xen_vaddr_t p2m_vaddr, p2m_end, mask, off;
+xen_pfn_t p2m_mfn, mfn, saved_mfn, max_pfn;
+uint64_t *ptes;
+xen_pfn_t *mfns;
+unsigned fpp, n_pages, level, shift, idx_start, idx_end, idx, saved_idx;
+int rc = -1;
+
+p2m_mfn = cr3_to_mfn(ctx, p2m_cr3);
+assert(p2m_mfn != 0);
+if ( p2m_mfn > ctx->x86_pv.max_mfn )
+{
+ERROR("Bad p2m_cr3 value %#lx", p2m_cr3);
+errno = ERANGE;
+return -1;
+}
+
+p2m_vaddr = GET_FIELD(ctx->x86_pv.shinfo, arch.p2m_vaddr,
+ ctx->x86_pv.width);
+fpp = PAGE_SIZE / ctx->x86_pv.width;
+ctx->x86_pv.p2m_frames = ctx->x86_pv.max_pfn / fpp + 1;
+p2m_end = p2m_vaddr + ctx->x86_pv.p2m_frames * PAGE_SIZE - 1;
+
+if ( ctx->x86_pv.width == 8 )
+{
+mask = 0xULL;
+if ( !is_canonical_address(p2m_vaddr) ||
+ !is_canonical_address(p2m_end) ||
+ p2m_end < p2m_vaddr ||
+ (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_64 &&
+ p2m_end > HYPERVISOR_VIRT_START_X86_64) )
+{
+ERROR("Bad virtual p2m address range %#lx-%#lx",
+ p2m_vaddr, p2m_end);
+errno = ERANGE;
+return -1;
+}
+}
+else
+{
+mask = 0xULL;
+if ( p2m_vaddr > mask || p2m_end > mask || p2m_end < p2m_vaddr ||
+ (p2m_vaddr <= HYPERVISOR_VIRT_END_X86_32 &&
+ p2m_end > HYPERVISOR_VIRT_START_X86_32) )
+{
+ERROR("Bad virtual p2m address range %#lx-%#lx",
+ p2m_vaddr, p2m_end);
+errno = ERANGE;
+return -1;
+}
+}
+
+DPRINTF("p2m list from %#lx to %#lx, root at %#lx", p2m_vaddr, p2m_end,
+p2m_mfn);
+DPRINTF("max_pfn %#lx, p2m_frames %d", ctx->x86_pv.max_pfn,
+ctx->x86_pv.p2m_frames);
+
+mfns = malloc(sizeof(*mfns));
+if ( !mfns )
+{
+ERROR("Cannot allocate memory for array of %u mfns", 1);
+goto err;
+}
+mfns[0] = p2m_mfn;
+off = 0;
+saved_mfn = 0;
+idx_start = idx_end = saved_idx = 0;
+
+for ( level = ctx->x86_pv.levels; level > 0; level-- )
+{
+n_pages = i
[Xen-devel] [PATCH v3 3/4] libxc: stop migration in case of p2m list structural changes
With support of the virtual mapped linear p2m list for migration it is
now possible to detect structural changes of the p2m list which before
would either lead to a crashing or otherwise wrong behaving domU.
A guest supporting the linear p2m list will increment the
p2m_generation counter located in the shared info page before and after
each modification of a mapping related to the p2m list. A change of
that counter can be detected by the tools and reacted upon.
As such a change should occur only very rarely once the domU is up the
most simple reaction is to cancel migration in such an event.
Signed-off-by: Juergen Gross
Reviewed-by: Andrew Cooper
---
tools/libxc/xc_sr_common.h | 12 +++
tools/libxc/xc_sr_save.c | 7 ++-
tools/libxc/xc_sr_save_x86_hvm.c | 7 +++
tools/libxc/xc_sr_save_x86_pv.c | 45
4 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 9aecde2..60b43e8 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -83,6 +83,15 @@ struct xc_sr_save_ops
int (*end_of_checkpoint)(struct xc_sr_context *ctx);
/**
+ * Check state of guest to decide whether it makes sense to continue
+ * migration. This is called in each iteration or checkpoint to check
+ * whether all criteria for the migration are still met. If that's not
+ * the case either migration is cancelled via a bad rc or the situation
+ * is handled, e.g. by sending appropriate records.
+ */
+int (*check_vm_state)(struct xc_sr_context *ctx);
+
+/**
* Clean up the local environment. Will be called exactly once, either
* after a successful save, or upon encountering an error.
*/
@@ -280,6 +289,9 @@ struct xc_sr_context
/* Read-only mapping of guests shared info page */
shared_info_any_t *shinfo;
+/* p2m generation count for verifying validity of local p2m. */
+uint64_t p2m_generation;
+
union
{
struct
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index cefcef5..88d85ef 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -394,7 +394,8 @@ static int send_dirty_pages(struct xc_sr_context *ctx,
DPRINTF("Bitmap contained more entries than expected...");
xc_report_progress_step(xch, entries, entries);
-return 0;
+
+return ctx->save.ops.check_vm_state(ctx);
}
/*
@@ -751,6 +752,10 @@ static int save(struct xc_sr_context *ctx, uint16_t
guest_type)
if ( rc )
goto err;
+rc = ctx->save.ops.check_vm_state(ctx);
+if ( rc )
+goto err;
+
if ( ctx->save.live )
rc = send_domain_memory_live(ctx);
else if ( ctx->save.checkpointed )
diff --git a/tools/libxc/xc_sr_save_x86_hvm.c b/tools/libxc/xc_sr_save_x86_hvm.c
index f3d6cee..e347b3b 100644
--- a/tools/libxc/xc_sr_save_x86_hvm.c
+++ b/tools/libxc/xc_sr_save_x86_hvm.c
@@ -175,6 +175,12 @@ static int x86_hvm_start_of_checkpoint(struct
xc_sr_context *ctx)
return 0;
}
+static int x86_hvm_check_vm_state(struct xc_sr_context *ctx)
+{
+/* no-op */
+return 0;
+}
+
static int x86_hvm_end_of_checkpoint(struct xc_sr_context *ctx)
{
int rc;
@@ -221,6 +227,7 @@ struct xc_sr_save_ops save_ops_x86_hvm =
.start_of_stream = x86_hvm_start_of_stream,
.start_of_checkpoint = x86_hvm_start_of_checkpoint,
.end_of_checkpoint = x86_hvm_end_of_checkpoint,
+.check_vm_state = x86_hvm_check_vm_state,
.cleanup = x86_hvm_cleanup,
};
diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index 40aa655..a0ec5c9 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -274,6 +274,39 @@ err:
}
/*
+ * Get p2m_generation count.
+ * Returns an error if the generation count has changed since the last call.
+ */
+static int get_p2m_generation(struct xc_sr_context *ctx)
+{
+uint64_t p2m_generation;
+int rc;
+
+p2m_generation = GET_FIELD(ctx->x86_pv.shinfo, arch.p2m_generation,
+ ctx->x86_pv.width);
+
+rc = (p2m_generation == ctx->x86_pv.p2m_generation) ? 0 : -1;
+ctx->x86_pv.p2m_generation = p2m_generation;
+
+return rc;
+}
+
+static int x86_pv_check_vm_state_p2m_list(struct xc_sr_context *ctx)
+{
+xc_interface *xch = ctx->xch;
+int rc;
+
+if ( !ctx->save.live )
+return 0;
+
+rc = get_p2m_generation(ctx);
+if ( rc )
+ERROR("p2m generation count changed. Migration aborted.");
+
+return rc;
+}
+
+/*
* Map the guest p2m frames specified via a cr3 value, a virtual address, and
* the maximum pfn. PTE entries are 64 bits vor both, 32 and 64 bit guests as
* in 32 bit case we support PAE guests only.
@@ -297,6 +330,8 @@ static int map_p2m_list(struct xc_sr_context
[Xen-devel] [PATCH v3 4/4] libxc: set flag for support of linear p2m list in domain builder
Set the SIF_VIRT_P2M_4TOOLS flag for pv-domUs in the domain builder to indicate the Xen tools have full support for the virtual mapped linear p2m list. This will enable pv-domUs to drop support of the 3 level p2m tree and use the linear list only. Without setting this flag some kernels might limit themselves to 512 GB memory size in order not to break migration. Signed-off-by: Juergen Gross Reviewed-by: Andrew Cooper --- docs/features/migration.pandoc| 7 --- tools/libxc/xc_dom_compat_linux.c | 2 +- tools/libxc/xc_dom_core.c | 2 ++ 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/features/migration.pandoc b/docs/features/migration.pandoc index 9852a19..151c50d 100644 --- a/docs/features/migration.pandoc +++ b/docs/features/migration.pandoc @@ -1,5 +1,5 @@ % Migration -% Revision 1 +% Revision 2 \clearpage @@ -95,7 +95,6 @@ scenarios, which will involve starting with VMs from Xen 4.5 # Areas for improvement * Arm support -* Linear P2M support for x86 PV * Live looping parameters # Known issues @@ -105,7 +104,8 @@ scenarios, which will involve starting with VMs from Xen 4.5 * x86 HVM with nested-virt (no relevant information included in the stream) * x86 PV ballooning (P2M marked dirty, target frame not marked) -* x86 PV P2M structure changes (not noticed, stale mappings used) +* x86 PV P2M structure changes (not noticed, stale mappings used) for + guests not using the linear p2m layout # References @@ -120,4 +120,5 @@ for Migration v2 Date Revision Version Notes -- --- 2015-10-24 1Xen 4.6 Document written +2015-12-11 2Xen 4.7 Support of linear p2m list -- --- diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c index abbc09f..c922c61 100644 --- a/tools/libxc/xc_dom_compat_linux.c +++ b/tools/libxc/xc_dom_compat_linux.c @@ -59,7 +59,7 @@ int xc_linux_build(xc_interface *xch, uint32_t domid, ((rc = xc_dom_ramdisk_file(dom, initrd_name)) != 0) ) goto out; -dom->flags = flags; +dom->flags |= flags; dom->console_evtchn = console_evtchn; dom->xenstore_evtchn = store_evtchn; diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c index 2061ba6..55c779d 100644 --- a/tools/libxc/xc_dom_core.c +++ b/tools/libxc/xc_dom_core.c @@ -777,6 +777,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch, dom->parms.elf_paddr_offset = UNSET_ADDR; dom->parms.p2m_base = UNSET_ADDR; +dom->flags = SIF_VIRT_P2M_4TOOLS; + dom->alloc_malloc += sizeof(*dom); return dom; -- 2.6.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST] make-flight: Support specifying a mini-os tree+revision
On Fri, 2015-12-11 at 15:16 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] make-flight: Support specifying a
> mini-os tree+revision"):
> > This is useful for standalone or adhoc use as well as (presumably)
> > bisection.
> >
> > There is no ap-* or cr-daily-* integration here because I didn't need
> > it (i.e. I'm not intending to create a new mini-os branch here).
>
> Acked-by: Ian Jackson
This patch fails when building 4.5 and earlier because extras/mini-os
exists but is part of xen.git not a separate repo, so dir_identify_vcs
goes:
2015-12-15 17:21:50 Z executing ssh ... osstest@10.80.229.171 cd
/home/osstest/build.38523.build-amd64/xen/tools/firmware/ovmf-dir && git
rev-parse HEAD^0
2015-12-15 17:21:50 Z runvar store: built_vcs_ovmf=git
2015-12-15 17:21:50 Z runvar store:
built_revision_ovmf=cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd
2015-12-15 17:21:50 Z executing ssh ... osstest@10.80.229.171
set -e
if ! test -e
/home/osstest/build.38523.build-amd64/xen/extras/mini-os; then echo none; exit
0; fi
cd /home/osstest/build.38523.build-amd64/xen/extras/mini-os
(test -e .git && echo git) ||
(test -d .hg && echo hg) ||
(echo >&2 'unable to determine vcs'; fail)
unable to determine vcs
bash: line 5: fail: command not found
I'm not sure if this is a bug (i.e. it was intended to be "echo fail") or
if it is deliberately using a non-existent command (which seems risky to
me).
All the other store_revisions refer to the symlink rather than the -remote
which is the actual clone (when one is made), so I don't think
s#extras/mini-os#extras/mini-os-remote# is the answer. Perhaps "fail"
should become "echo fail" and store_revision should treat that like it does
fail (which is to accept it if $optional).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] How to change/set preferred SSL cipher suite for relocation (migration)?
On Wed, 2015-12-16 at 01:01 +0330, Alireza Vaezi wrote:
> I'm using Xen 4.4.2 and I need to be able to change or set my preferred
> (available) ssl cipher suit like RC4-SHA, or DES-CBC-SHA , etc. to be
> further used in relocation/migration of domU via ssl.
>
> I suppose I need to make changes in Xen's source code and make-install it
> again, yet I don't know where to go and what to change.
Despite appearances this is really a question for xen-users.
"xl migrate" just uses ssh, so you can write whatever options you want into
.ssh/config, including per destination host parameters or whatever.
There is also the -s option which gives a command which is called instead
of ssh, it gets given the $desthost and the command to run there ("xl
migrate-receive [options]") and can use whatever transport it likes to make
that happen (custom ssh command, talking to a custom daemon on the remote
end, etc).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: sort and update tree info
On Wed, 2015-12-16 at 00:50 -0700, Jan Beulich wrote: > Move a few misplaced entries into their intended (alphabetical) slots. > > Update qemu and mini-os tree info. > > Signed-off-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools/symbols: document binutils commits for issues needing workarounds so far
On Wed, 2015-12-16 at 00:53 -0700, Jan Beulich wrote:
> Also the issue 3rd issue mentioned in commit d37d63d4b5 ("symbols:
> prefix static symbols with their source file names") has been fixed by
> binutils commit 270f824531 (also expected to appear in 2.27).
>
> Signed-off-by: Jan Beulich
Acked-by: Ian Campbell
> --- a/xen/tools/symbols.c
> +++ b/xen/tools/symbols.c
> @@ -105,15 +105,18 @@ static int read_symbol(FILE *in, struct
>
> sym = strrchr(str, '.');
> if (strcasecmp(type, "FILE") == 0 ||
> - (/* GNU nm prior to XXX doesn't produce a type for EFI
> binaries. */
> + (/*
> + * GNU nm prior to binutils commit 552e55ed06 (expected to
> + * appear in 2.27) doesn't produce a type for EFI binaries.
> + */
> input_format == fmt_sysv && !*type && stype == '?' && sym
> &&
> sym[1] && strchr("cSsoh", sym[1]) && !sym[2])) {
> /*
> - * gas prior to XXX outputs symbol table entries
> resulting
> - * from .file in reverse order. If we get two
> consecutive file
> - * symbols, prefer the first one if that names an object
> file
> - * or has a directory component (to cover multiply
> compiled
> - * files).
> + * gas prior to binutils commit fbdf9406b0 (expected to
> appear
> + * in 2.27) outputs symbol table entries resulting from
> .file
> + * in reverse order. If we get two consecutive file
> symbols,
> + * prefer the first one if that names an object file or
> has a
> + * directory component (to cover multiply compiled
> files).
> */
> bool multi = strchr(str, '/') || (sym && sym[1] == 'o');
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/9] xenstore: install init-xenstore-domain via make install
On Wed, 2015-12-16 at 07:27 +0100, Juergen Gross wrote: > On 15/12/15 22:41, Daniel De Graaf wrote: > > On 15/12/15 07:16, Ian Campbell wrote: > > > On Fri, 2015-12-11 at 16:47 +0100, Juergen Gross wrote: > > > > The program init-xenstore-domain to start a xenstore domain instead > > > > of the xenstored daemon is built, but not installed. Change that. > > > > > > > > Signed-off-by: Juergen Gross > > > > > > Acked-by: Ian Campbell > > > > > > CCing Daniel too since he has an interest in this mode of operation. > > > > > > I appreciate the CONFIG_Linux thing is pre-existing, and stems from > > > being > > > unable to build stubdoms on other platforms, but should we consider > > > building these supporting tools anyway, after all a user might get a > > > suitable stubdom via some other means? > > > > Yes, this is actually rather easy to do: compile the stubdom on Linux > > and > > just copy the .gz over; starting a stubdom doesn't actually rely on > > using > > the tool. > > > > The reason this is linux-specific is that the > > IOCTL_XENBUS_BACKEND_SETUP > > call on /dev/xen/xenbus_backend is (afaik) only implemented in Linux. > > If > > this changes, or if it compiles anyway, then I see no problem. > > Aah, thanks for this information. > > So currently the required dom0 driver functionality for xenstore domain > is available on Linux only. > > Basically I think it makes no sense to have a tool built and installed > which can just say "sorry, I won't work" on the target system. I'll > just leave the patch as it is. Ian? Yep, given that ioctl is Linux only I agree. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.
On Tue, 2015-12-15 at 16:15 -0700, Jim Fehlig wrote: > On 12/14/2015 04:37 AM, Ian Campbell wrote: > > On Mon, 2015-12-14 at 11:15 +, Daniel P. Berrange wrote: > > > On Thu, Dec 10, 2015 at 11:38:36AM +, Ian Campbell wrote: > > > > Upstream Xen is in the process of splitting the (stable API) xtl_* > > > > interfaces out from the (unstable API) libxenctrl library and into > > > > a > > > > new (stable API) libxentoollog. > > > > > > > > In order to be compatible with Xen both before and after this > > > > transition check for xtl_createlogger_stdiostream in a > > > > libxentoollog > > > > library and use it if present. If it is not present assume it is in > > > > libxenctrl. > > > Ok, so there's no API changes, just move stuf from one to the other. > > Indeed, it should really have been a separate library all along and the > > API > > already setup that way. > > > > I'm working on some other library splits, which will involve API > > changes, > > but AFAIK they are all isolated from libvirt via the use of libxl, so > > there > > should be no churn for you guys other than this one patch. > > > > > > It might be nice to get this into 1.3.0 so that supports Xen 4.7 > > > > out > > > > of the box? Not sure what the libvirt stable backport policy is but > > > > it > > > > might also be good to eventually consider it for that? > > > We've missed 1.3.0 release, but I'd be ok with adding it to the > > > stable branch if that's going to be useful. > > I think it would, to allow things to build with Xen 4.7 (when it is > > released). > > I'm not sure it is necessary. libvirt is released monthly, so there will be > several releases before Xen 4.7 is released. AH, I didn't realise it was on such a fast cadence, that's ok then. > > [...] > > > > > Looks, fine from me but will let Jim push it. > > I've pushed the patch to master, but not the 1.3.0 maint branch. It will be > included in the 1.3.1 release planned for mid January. Ian, do you think that > is > sufficient? Easily, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Xen: support maxvcpus in xm and xl config
On Tue, 2015-12-15 at 15:20 -0700, Jim Fehlig wrote: > From: Ian Campbell > > xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail > as a bit map of which cpus are online (default is all). > > xend from 4.0 onwards understands maxvcpus as maxvcpus and > vcpus as the number which are online (from 0..N-1). The > upstream commit (68a94cf528e6 "xm: Add maxvcpus support") > claims that if maxvcpus is omitted then the old behaviour > (i.e. obeying vcpu_avail) is retained, but AFAICT it was not, > in this case vcpu==maxcpus==online cpus. This is good for us > because handling anything else would be fiddly. > > This patch changes parsing of the virDomainDef maxvcpus and vcpus > entries to use the corresponding 'maxvcpus' and 'vcpus' settings > from xm and xl config. It also drops use of the old Xen 3.x > 'vcpu_avail' setting. > > The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since > maxvcpus is simply a count, not a bit mask), which is particularly > crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are > expected to support vcpu placement, and therefore only the boot > vcpu's info lives in the shared info page). > > Existing tests adjusted accordingly, and new tests added for the > 'maxvcpus' setting. > > Signed-off-by: Jim Fehlig Acked-by: Ian Campbell Tested-by: Ian Campbell (as far as "domxml-from-native xen-xl" goes, I seem to have another issue actually starting a domain on ARM, which I'll investigate...) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC XEN v1 05/14] xen: arm: Implement basic XEN_DOMCTL_{set, get}hvmcontext support
On Tue, 2015-12-15 at 18:00 +, Stefano Stabellini wrote:
> On Wed, 9 Dec 2015, Ian Campbell wrote:
> > This is just the minimally required basic infra and header, no actual
> > useful data is saved yet.
> >
> > Signed-off-by: Ian Campbell
> > ---
> > xen/arch/arm/Makefile | 1 +
> > xen/arch/arm/domctl.c | 74
> > ++
> > xen/arch/arm/save.c| 53
> > xen/common/Makefile| 2 +
> > xen/include/asm-arm/hvm/support.h | 25
> > xen/include/public/arch-arm/hvm/save.h | 17
> > 6 files changed, 172 insertions(+)
> > create mode 100644 xen/arch/arm/save.c
> > create mode 100644 xen/include/asm-arm/hvm/support.h
> >
> > diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> > index 4ac5edd..5a96486 100644
> > --- a/xen/arch/arm/Makefile
> > +++ b/xen/arch/arm/Makefile
> > @@ -40,6 +40,7 @@ obj-y += device.o
> > obj-y += decode.o
> > obj-y += processor.o
> > obj-y += smc.o
> > +obj-y += save.o
> >
> > #obj-bin-y += o
> >
> > diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> > index d3459ee..3403e23 100644
> > --- a/xen/arch/arm/domctl.c
> > +++ b/xen/arch/arm/domctl.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -134,6 +135,79 @@ long arch_do_domctl(struct xen_domctl *domctl,
> > struct domain *d,
> > break;
> > }
> >
> > +case XEN_DOMCTL_sethvmcontext:
> > +{
> > +struct hvm_domain_context c = { .size = domctl-
> > >u.hvmcontext.size };
>
> if ( d == currend->domain )
> return some_kind_of_error;
> ?
I'd be inclined to put that into the common code so either hvm_load, or
with your suggestion later to make this common (which sounds doable) here.
Not sure about the get case, there might be reasons other than migration to
want to get at this state? (Maybe nothing other than debug hacking I guess)
[...]
> Actually now that I have read the patch, I think that rather than
> duplicating the code, we should just move the x86 implementation of
> XEN_DOMCTL_sethvmcontext and XEN_DOMCTL_gethvmcontext to common code.
> The differences are negligible.
Yes, I'll give that a go.
>
> > +#ifndef __ASM_ARM_HVM_SUPPORT_H__
> > +#define __ASM_ARM_HVM_SUPPORT_H__
> > +
> > +#include
> > +#include
> > +
> > +#endif /* __ASM_ARM_HVM_SUPPORT_H__ */
>
> Interestingly I can compile Xen on x86_64 just fine removing the
> #include in xen/common/hvm/save.c. I think that is a
> better option than introducing this empty header file.
I'll give that a go, it might be invalidated by the consolidation you
suggest above, but in that case the empty header is the lesser evil.
> > diff --git a/xen/include/public/arch-arm/hvm/save.h
> > b/xen/include/public/arch-arm/hvm/save.h
> > index 75b8e65..5f4de94 100644
> > --- a/xen/include/public/arch-arm/hvm/save.h
> > +++ b/xen/include/public/arch-arm/hvm/save.h
> > @@ -26,6 +26,23 @@
> > #ifndef __XEN_PUBLIC_HVM_SAVE_ARM_H__
> > #define __XEN_PUBLIC_HVM_SAVE_ARM_H__
> >
> > +#define HVM_FILE_MAGIC 0x92385520
>
> Out of curiousity, how did you come up with the number? Just making sure
> there is no secret message in there.
I appear to have gotten it from the original Samsung patches.
If there is a secret message then I can't spot it, it's nothing in ascii at
least (8U).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC XEN v1 06/14] xen: arm: Add some basic platform info to save header
On Tue, 2015-12-15 at 18:37 +, Stefano Stabellini wrote:
> On Wed, 9 Dec 2015, Ian Campbell wrote:
> > These correspond to the content of struct xen_arch_domainconfig.
> >
> > On restore various things are checked, mostly to ensure they match the
> > hardcoded things of the restoring Xen.
> >
> > Signed-off-by: Ian Campbell
> > ---
> > xen/arch/arm/save.c| 44
> > ++
> > xen/include/public/arch-arm/hvm/save.h | 6 +
> > 2 files changed, 50 insertions(+)
> >
> > diff --git a/xen/arch/arm/save.c b/xen/arch/arm/save.c
> > index 6a1934b..7b34782 100644
> > --- a/xen/arch/arm/save.c
> > +++ b/xen/arch/arm/save.c
> > @@ -21,6 +21,17 @@
> >
> > void arch_hvm_save(struct domain *d, struct hvm_save_header *hdr)
> > {
> > +switch ( d->arch.vgic.version )
> > +{
> > +case GIC_V2: hdr->gic_version = XEN_DOMCTL_CONFIG_GIC_V2; break;
> > +case GIC_V3: hdr->gic_version = XEN_DOMCTL_CONFIG_GIC_V3; break;
> > +default: BUG();
> > +}
> > +
> > +hdr->nr_spis = d->arch.vgic.nr_spis;
> > +hdr->clock_frequency = cpu_khz;
> > +
> > +hdr->evtchn_irq = GUEST_EVTCHN_PPI;
> > }
> >
> > int arch_hvm_load(struct domain *d, struct hvm_save_header *hdr)
> > @@ -39,6 +50,39 @@ int arch_hvm_load(struct domain *d, struct
> > hvm_save_header *hdr)
> > return -1;
> > }
> >
> > +switch ( hdr->gic_version )
> > +{
> > +case XEN_DOMCTL_CONFIG_GIC_V2: d->arch.vgic.version = GIC_V2;
> > break;
> > +case XEN_DOMCTL_CONFIG_GIC_V3: d->arch.vgic.version = GIC_V3;
> > break;
> > +default:
> > +printk(XENLOG_G_ERR "HVM%d restore: unsupported gic version
> > %u\n",
> > + d->domain_id, hdr->gic_version);
> > +return -1;
> > +}
> > +
> > +if ( hdr->nr_spis )
> > +{
> > +printk(XENLOG_G_ERR "HVM%d restore: cannot support nr_spis !=
> > 0, %u\n",
> > + d->domain_id, hdr->nr_spis);
> > +return -1;
> > +}
> > +
> > +if ( hdr->clock_frequency != cpu_khz )
> > +{
> > +printk(XENLOG_G_ERR
> > +"HVM%d restore: unsupported guest clock %"PRId32"kHz on
> > host @ %ldkHz\n",
> > +d->domain_id, hdr->clock_frequency, cpu_khz);
> > +return -1;
> > +}
> > +
> > +if ( hdr->evtchn_irq != GUEST_EVTCHN_PPI )
> > +{
> > +printk(XENLOG_G_ERR
> > +"HVM%d restore: unsupported guest evtchn IRQ%u host uses
> > IRQ%u\n",
> > +d->domain_id, hdr->evtchn_irq, GUEST_EVTCHN_PPI);
> > +return -1;
> > +}
> > +
> > return 0;
> > }
> >
> > diff --git a/xen/include/public/arch-arm/hvm/save.h
> > b/xen/include/public/arch-arm/hvm/save.h
> > index 5f4de94..6f1be37 100644
> > --- a/xen/include/public/arch-arm/hvm/save.h
> > +++ b/xen/include/public/arch-arm/hvm/save.h
> > @@ -34,6 +34,12 @@ struct hvm_save_header
> > uint32_t magic; /* Must be HVM_FILE_MAGIC */
> > uint32_t version; /* File format version */
> > uint64_t changeset; /* Version of Xen that saved this file
> > */
> > +
> > +uint8_t gic_version; /* XEN_DOMCTL_CONFIG_GIC_v* (_NOT_
> > _NATIVE) */
> > +uint32_t nr_spis; /* Currently must be 0 */
> > +uint32_t clock_frequency; /* kHz */
> > +
> > +uint32_t evtchn_irq;
>
> I would prefer if you added these in the previous patch, or maybe
> better, you introduced HVM_FILE_VERSION only with the last patch.
> Otherwise theoretically you would have to bump HVM_FILE_VERSION with
> this patch.
I'm not terribly concerned with save file versioning in the midst of the
series which implements save/restore, it's ludicrous to suggest we might be
required to support save/restore with this series half applied, but I'll
fold it in anyway.
> The rest looks good.
Thanks.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] flask: Allow device model to raise PCI interrupts (pcilevel capability)
On Tue, 2015-12-15 at 16:34 -0500, Daniel De Graaf wrote:
> On 14/12/15 07:05, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH] flask: Allow device model to raise PCI
> > interrupts (pcilevel capability)"):
> > ...
> > > - allow $1 $2_target:hvm { getparam setparam trackdirtyvram
> > > hvmctl irqlevel pciroute cacheattr send_irq };
> > > + allow $1 $2_target:hvm { getparam setparam trackdirtyvram
> > > hvmctl irqlevel pciroute pcilevel cacheattr send_irq };
> >
> > Thanks for tracking this down.
> >
> > Based on xen/xsm/flask/policy/access_vectors this seems like a
> > no-brainer. Hopefully Daniel will agree :-).
> >
> > Acked-by: Ian Jackson
> >
> > Ian.
>
> Yep, this change is obvious given the issue. I didn't find any other
> missing XSM_DM_PRIV accesses when I walked through them, so hopefully
> this is the only one that wasn't correct.
FWIW I didn't see any other AVC messages in the logs when a ran this
through an ad-hoc osstest job, so I'm hopeful that your hopefulness is not
misplaced ;-)
> Acked-by: Daniel De Graaf
Thanks, applied.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 2/8] xen: Add support for VMware cpuid leaves
>>> On 28.11.15 at 22:44, wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -290,6 +290,7 @@ struct xen_arch_domainconfig {
> XEN_X86_EMU_VGA | XEN_X86_EMU_IOMMU |
> \
> XEN_X86_EMU_PIT)
> uint32_t emulation_flags;
> +uint64_t vmware_hwver;
It's been a while since the last iteration, so could you please remind
me again why this needs to be a 64-bit quantity?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 03/28] build: build Kconfig and config rules
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Wire in the Kconfig build and makefile rules to be able to generate > valid configuration files to be used by the build process but don't > actually use the output for affecting the Xen build. To avoid dragging > in most of Kbuild from the Linux kernel this adds Makefile.kconfig which > is our real entry point into building kconfig. This attempts to reuse as > much of the Xen build bits as possible and wire them to the bits that > kconfig expects to be provided by Kbuild. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Doug Goldstein Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 04/28] build: use generated Kconfig options for Xen
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Switches the build system to rely on the options and flags generated by > Kconfig to control what gets built and how. Follow on patches will > convert items to be prefixed with CONFIG_. Additionally remove a #define > that resulted in a redefined variable when building for arm. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 00/28] Kconfig conversion
On Tue, 2015-12-15 at 07:12 -0600, Doug Goldstein wrote: > The patch series can be grabbed at: > https://github.com/cardoe/xen/tree/kconfig_v8 I tried this with: $ git clean -fdqx xen $ make -C xen XEN_TARGET_ARCH=arm64 defconfig Followed by running my usual build script which does: + make -C xen XEN_TARGET_ARCH=arm64 DESTDIR=/tmp/tmpW3nFxB /local/scratch/ianc/devel/arm/xen.git/xen/ debug=y CROSS_COMPILE=aarch64-linux-gnu- CONFIG_EARLY_PRINTK=fastmodel install make: Entering directory '/local/scratch/ianc/devel/arm/xen.git/xen' make -f /local/scratch/ianc/devel/arm/xen.git/xen/Rules.mk -C /local/scratch/ianc/devel/arm/xen.git/xen built_in.o built_in_bin.o make[1]: Entering directory '/local/scratch/ianc/devel/arm/xen.git/xen' aarch64-linux-gnu-ld-EL -EL -r -o built_in.o aarch64-linux-gnu-ld: no input files /local/scratch/ianc/devel/arm/xen.git/xen/Rules.mk:143: recipe for target 'built_in.o' failed make[1]: *** [built_in.o] Error 1 make[1]: Leaving directory '/local/scratch/ianc/devel/arm/xen.git/xen' Makefile:232: recipe for target '/local/scratch/ianc/devel/arm/xen.git/xen/' failed make: *** [/local/scratch/ianc/devel/arm/xen.git/xen/] Error 2 make: Leaving directory '/local/scratch/ianc/devel/arm/xen.git/xen' E: failed: make -C xen XEN_TARGET_ARCH=arm64 DESTDIR=/tmp/tmpW3nFxB /local/scratch/ianc/devel/arm/xen.git/xen/ debug=y CROSS_COMPILE=aarch64-linux-gnu- CONFIG_EARLY_PRINTK=fastmodel install + rm -rf /tmp/tmpW3nFxB Adding -j12 also got another error which I suppose was blocked by the above: aarch64-linux-gnu-gcc -O1 -fno-omit-frame-pointer -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -I/local/scratch/ianc/devel/arm/xen.git/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -mcpu=generic -mgeneral-regs-only -DGCC_HAS_VISIBILITY_ATTRIBUTE -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /local/scratch/ianc/devel/arm/xen.git/xen/include/xen/config.h '-D__OBJECT_FILE__="asm-offsets.s"' -fno-optimize-sibling-calls -DCONFIG_EARLY_PRINTK -DEARLY_PRINTK_INIT_UART -DEARLY_PRINTK_INC=\"debug-pl011.inc\" -DEARLY_PRINTK_BAUD=115200 -DEARLY_UART_BASE_ADDRESS=0x1c09 -DEARLY_UART_REG_SHIFT= -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF ./.asm-offsets.s.d -S -o asm-offsets.s arm64/asm-offsets.c In file included from :0:0: /local/scratch/ianc/devel/arm/xen.git/xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h: No such file or directory #include ^ Running oldconfig didn't help. I'm not sure what's wrong, x86_64 seems to behave the same. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 04/28] build: use generated Kconfig options for Xen
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Switches the build system to rely on the options and flags generated by > Kconfig to control what gets built and how. Follow on patches will > convert items to be prefixed with CONFIG_. Additionally remove a #define > that resulted in a redefined variable when building for arm. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 05/28] build: convert HAS_PASSTHROUGH use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated HAS_PASSTHROUGH defines for the code base. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > CC: Daniel De Graaf > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 06/28] build: convert HAS_DEVICE_TREE use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_DEVICE_TREE defines in the code > base. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Jan Beulich > CC: Daniel De Graaf > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 08/28] build: convert HAS_NS16550 use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_NS16550 defines in the code base. > > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 11/28] build: convert HAS_VIDEO use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_VIDEO defines in the code base. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 17/28] build: convert HAS_ARM_HDLCD use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_ARM_HDLCD defines in the code base. > > CC: Ian Campbell > CC: Stefano Stabellini > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 15/28] build: convert HAS_PDX use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_PDX defines in the code base. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 20/28] build: convert HAS_EXYNOS4210 use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_EXYNOS4210 defines in the code base. > > CC: Ian Campbell > CC: Ian Jackson > CC: Jan Beulich > CC: Keir Fraser > CC: Tim Deegan > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 19/28] build: convert HAS_PL011 use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_PL011 defines in the code base. > > CC: Ian Campbell > CC: Ian Jackson > CC: Jan Beulich > CC: Keir Fraser > CC: Tim Deegan > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 18/28] build: convert HAS_CADENCE_UART use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_CADENCE_UART defines in the code > base. > > CC: Ian Campbell > CC: Ian Jackson > CC: Jan Beulich > CC: Keir Fraser > CC: Tim Deegan > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 21/28] build: convert HAS_OMAP use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_OMAP defines in the code base. > > CC: Ian Campbell > CC: Ian Jackson > CC: Jan Beulich > CC: Keir Fraser > CC: Tim Deegan > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 22/28] build: convert HAS_SCIF use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_SCIF defines in the code base. > > CC: Ian Campbell > CC: Ian Jackson > CC: Jan Beulich > CC: Keir Fraser > CC: Tim Deegan > Signed-off-by: Doug Goldstein > Acked-by: Jan Beulich Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 27/28] build: convert HAS_GICV3 use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base. > > CC: Ian Campbell > CC: Stefano Stabellini > Signed-off-by: Doug Goldstein Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 25/28] build: convert HAS_MEM_PAGING use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_MEM_PAGING defines in the code base. > > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > CC: Razvan Cojocaru > CC: Tamas K Lengyel > CC: Daniel De Graaf > Signed-off-by: Doug Goldstein > Acked-by: Razvan Cojocaru Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 24/28] build: convert HAS_MEM_ACCESS use to Kconfig
On Tue, 2015-12-15 at 07:13 -0600, Doug Goldstein wrote: > Use the Kconfig generated CONFIG_HAS_MEM_ACCESS defines in the code base. > > CC: Ian Campbell > CC: Stefano Stabellini > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > CC: Razvan Cojocaru > CC: Tamas K Lengyel > CC: Daniel De Graaf > Signed-off-by: Doug Goldstein > Acked-by: Razvan Cojocaru Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 00/28] Kconfig conversion
On Wed, 2015-12-16 at 00:37 -0700, Jan Beulich wrote: > > > > On 15.12.15 at 14:12, wrote: > > The following series is a follow on to the Kconfig conversion patch > > series. > > There are still more components to convert however this is the bare > > minimal > > to get everything working and get the options out of the existing > > makefiles. > > > > The CONFIG_HAS_ variables are there to match the behavior of the Linux > > CONFIG_HAVE_ variables. The purpose is to say that this > > hardware/profile/env > > supports this option while the CONFIG_ variable states that this option > > was > > requested on/off by user intervention. > > > > Ultimately my goal is to allow for more parts of the hypervisor to be > > turned > > off at compile time and potentially make it easier to include more > > experimental features by others which can be turned off by default. > > Also to > > provide the one true location for all possible knobs in the source > > code. > > > > The patch series can be grabbed at: > > https://github.com/cardoe/xen/tree/kconfig_v8 > > > > Change since v7: > > - rebased on top of split out patches that have been merged > > - functionally the behavior is identical mostly comment and variable > > changes > > Patches 1, 3, 4, 12, and 23-26 now also > Acked-by: Jan Beulich > > I didn't check each of the patches, but with the XSM acks having > come in, the main missing thing at this point for at least an initial > part of the series to go in seem to be ARM side acks. I've acked all the ARM ones I spotted based on diffstat, if I've missed something or there was THE REST code where my input is needed the a pointer would be appreciated. However as I've just reported there is something broken with the overall workflow (make defconfg + make doesn't seem to work for me), which I obviously consider a blocker for actually applying, even if I happen to have acked the patch which is responsible... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 00/28] Kconfig conversion
On Wed, 2015-12-16 at 10:33 +, Ian Campbell wrote: > On Tue, 2015-12-15 at 07:12 -0600, Doug Goldstein wrote: > > The patch series can be grabbed at: > > https://github.com/cardoe/xen/tree/kconfig_v8 > > I tried this with: > > $ git clean -fdqx xen > $ make -C xen XEN_TARGET_ARCH=arm64 defconfig > > Followed by running my usual build script which does: > > + make [...] install NB, it also fails with "build" instead of "install", or if I omit the defconfig step (which I assume needs to work so that top-level "make dist" does the right thing). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: add myself for kconfig
On 12/16/15 1:27 AM, Jan Beulich wrote:
On 15.12.15 at 23:39, wrote:
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -139,6 +139,12 @@ F: xen/drivers/char/omap-uart.c
>> F: xen/drivers/char/pl011.c
>> F: xen/drivers/passthrough/arm/
>>
>> +KCONFIG
>> +M: Doug Goldstein
>> +S: Supported
>> +F: docs/misc/kconfig{,-language}.txt
>> +F: xen/tools/kconfig/
>> +
>> HISILICON HIP04 SUPPORT
>
> I'm sorry, but - no, this is not any better than the original (irrespective
> of this HSILICON entry being misplaced too).
>
> Jan
>
Honestly I have no idea why I put it there.
--
Doug Goldstein
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] hvmlite: document the BSP/AP boot ABI
On Tue, 2015-12-15 at 18:27 +0100, Roger Pau Monne wrote: > The discussion in [1] lead to an agreement of the missing pieces in PVH > (or HVM without a device-model) in order to progress with it's > implementation. > > One of the missing pieces is a new boot ABI, that replaces the PV boot > ABI. The aim of this new boot ABI is to remove the limitations of the > PV boot ABI, that are no longer present when using auto-translated > guests. The new boot protocol should allow to use the same entry point > for both 32bit and 64bit guests, and let the guest choose it's bitness > at run time without the domain builder knowing in advance. > > This patch introduces a new document called hvmlite.markdown, with the > intention of merging it into pvh.markdown once the HVMlite implementation > has feature parity with PVH and the old PVH ABI is replaced with the > HVMlite one. > > [1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00258.html > > Signed-off-by: Roger Pau Monné > --- > Cc: Ian Campbell > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Tim Deegan > Cc: Andrew Cooper > --- > docs/misc/hvmlite.markdown | 82 > ++ > 1 file changed, 82 insertions(+) > create mode 100644 docs/misc/hvmlite.markdown > > diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown > new file mode 100644 > index 000..00ae423 > --- /dev/null > +++ b/docs/misc/hvmlite.markdown > @@ -0,0 +1,82 @@ > +**NOTE**: this document will be merged into `pvh.markdown` once PVH is > replaced > +with the HVMlite implementation. > + > +# HVM direct boot ABI # > + > +Since the Xen entry point into the kernel can be different from the > +native entry point, a `ELFNOTE` is used in order to tell the domain > +builder how to load and jump into the kernel entry point: > + > +ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY, .long, xen_start32) > + > +The presence of the `XEN_ELFNOTE_PHYS32_ENTRY` note indicates that the > +kernel supports the boot ABI described in this document. > + > +The domain builder will load the kernel into the guest memory space and > +jump into the entry point defined at `XEN_ELFNOTE_PHYS32_ENTRY` with the > +following machine state: > + > + * `ebx`: contains the physical memory address where the loader has > placed > + the boot start info structure. > + > + * `cr0`: bit 0 (PE) will be set. All the other writeable bits are > cleared. > + > + * `cr4`: all bits are cleared. > + > + * `cs`: must be a 32-bit read/execute code segment with a base of ‘0’ > + and a limit of ‘0x’. The selector value is unspecified. > + > + * `ds`, `es`: must be a 32-bit read/write data segment with a base of > + ‘0’ and a limit of ‘0x’. The selector values are all > unspecified. > + > + * `tr`: must be a 32-bit TSS (active) with a base of '0' and a limit of > '0x67'. > + > + * `eflags`: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared. > + Bit 8 (TF) must be cleared. Other bits are all unspecified. This list uses a mixture of "will be" and "must be", i.e. flips between producer's and consumer's point of view. I have no opinion on the technical content. Might be nice to prepend x86/ to the "HVM direct boot ABI" title, but meh. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Xen: support maxvcpus in xm and xl config
On Wed, 2015-12-16 at 10:11 +, Ian Campbell wrote: > On Tue, 2015-12-15 at 15:20 -0700, Jim Fehlig wrote: > > From: Ian Campbell > > > > xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail > > as a bit map of which cpus are online (default is all). > > > > xend from 4.0 onwards understands maxvcpus as maxvcpus and > > vcpus as the number which are online (from 0..N-1). The > > upstream commit (68a94cf528e6 "xm: Add maxvcpus support") > > claims that if maxvcpus is omitted then the old behaviour > > (i.e. obeying vcpu_avail) is retained, but AFAICT it was not, > > in this case vcpu==maxcpus==online cpus. This is good for us > > because handling anything else would be fiddly. > > > > This patch changes parsing of the virDomainDef maxvcpus and vcpus > > entries to use the corresponding 'maxvcpus' and 'vcpus' settings > > from xm and xl config. It also drops use of the old Xen 3.x > > 'vcpu_avail' setting. > > > > The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since > > maxvcpus is simply a count, not a bit mask), which is particularly > > crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are > > expected to support vcpu placement, and therefore only the boot > > vcpu's info lives in the shared info page). > > > > Existing tests adjusted accordingly, and new tests added for the > > 'maxvcpus' setting. > > > > Signed-off-by: Jim Fehlig > > Acked-by: Ian Campbell > Tested-by: Ian Campbell > (as far as "domxml-from-native xen-xl" goes, I seem to have another issue > actually starting a domain on ARM, which I'll investigate...) Turned out to be a mismatch between my build-time and run-time libxl versions, fixed by a clean rebuild. So that's a full Tested-by. I noticed that the newer cmdline= (inplace of root=+extra= etc) wasn't supported. I'll knock something up. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 00/10] xen/arm: Implement the hypercall handling in assembly
On Tue, 2015-12-15 at 18:33 +, Andrew Cooper wrote: > On 15/12/15 17:51, Julien Grall wrote: > > Hi all, > > > > This patch aims is a first attempt to write the hypercall dispatch in > > assembly > > in order to avoid reloading the hypercall arguments from the stack. > > Why? A couple of stack operations are in the noise, performance wise. At least on ARM It's quite a bit more than a couple (dozens but not hundreds I would say, and I've not looked at the patch yet to see how much it saves out of those), but clearly it would need to be measured at some point before taking it too much further than an RFC. There's a second issue which is that the current C dispatch table approach which uses a common typedef is not strictly speaking valid C, since it is undefined behaviour to call a function through a typedef which has a different prototype (Ian J can probably explain it better than I, with chapter and verse etc). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 66395: regressions - FAIL
flight 66395 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/66395/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 65643 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail like 65643 test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 65643 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 65643 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 65643 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 65643 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass version targeted for testing: xen 4c11414775a28ccd29a33c62cd89e202feb631d7 baseline version: xen a84cecd5c70e5db264ad94cbb29af26e6d1b7c40 Last test of basis65643 2015-12-09 23:38:54 Z6 days Testing same since66395 2015-12-15 18:18:26 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Daniel Kiper Dario Faggioli David Vrabel Haozhong Zhang Jan Beulich Kevin Tian jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-fre
Re: [Xen-devel] Question about VirtIO on Xen - Disk performance issues
Hello Luca, the recommended way to increase disk performance would be to use Xen PV disks. You just need to install the Windows PV drivers: http://www.xenproject.org/developers/teams/windows-pv-drivers.html But using VirtIO disk should also increase performance, even though most probably not as much. Cheers, Stefano On Tue, 15 Dec 2015, Luca Tongiani wrote: > Hi to all, > I'm writing you this mail for asking some advice about a great problem i'm > havin in running a Windows VM > (HVM) onto a Xen (Gentoo based) Hypevisor. > > I need to achieve maximum performance from this VM because of intense SQL > tasks running in it. > > I've seen good improvement in IO on disk using VirtIO on a Windows VM onto a > QEMU (QNAP) hypervisor, and i'm > tryin to use this feature also on my Xen HV. > Is VirtIO disk a good way to improve performance? > > Thx in advance and hope to keep in touch > -- > > Luca Tongiani > > Sinte srl > Soluzioni Informatiche e Telematiche > via Monte Grappa 4/B > 20900 Monza (MB) > > Cel (+39) 339 745 49 21 > Tel (+39) 039 200 59 60 > Fax (+39) 039 200 69 42 > Web www.sinte.net > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] squash into 'build: use generated Kconfig options for Xen'
Signed-off-by: Doug Goldstein --- xen/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/Makefile b/xen/Makefile index 487eeaa..9023863 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -33,7 +33,7 @@ default: build .PHONY: dist dist: install -build:: include/config/auto.conf +build install:: include/config/auto.conf .PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags build install uninstall debug clean distclean cscope TAGS tags MAP gtags:: -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 00/28] Kconfig conversion
On 12/16/15 4:33 AM, Ian Campbell wrote: > On Tue, 2015-12-15 at 07:12 -0600, Doug Goldstein wrote: >> The patch series can be grabbed at: >> https://github.com/cardoe/xen/tree/kconfig_v8 > > I tried this with: > > $ git clean -fdqx xen > $ make -C xen XEN_TARGET_ARCH=arm64 defconfig > > Followed by running my usual build script which does: > > + make -C xen XEN_TARGET_ARCH=arm64 DESTDIR=/tmp/tmpW3nFxB > /local/scratch/ianc/devel/arm/xen.git/xen/ debug=y > CROSS_COMPILE=aarch64-linux-gnu- CONFIG_EARLY_PRINTK=fastmodel install > make: Entering directory '/local/scratch/ianc/devel/arm/xen.git/xen' > make -f /local/scratch/ianc/devel/arm/xen.git/xen/Rules.mk -C > /local/scratch/ianc/devel/arm/xen.git/xen built_in.o built_in_bin.o > make[1]: Entering directory '/local/scratch/ianc/devel/arm/xen.git/xen' > aarch64-linux-gnu-ld-EL -EL -r -o built_in.o > aarch64-linux-gnu-ld: no input files > /local/scratch/ianc/devel/arm/xen.git/xen/Rules.mk:143: recipe for target > 'built_in.o' failed > make[1]: *** [built_in.o] Error 1 > make[1]: Leaving directory '/local/scratch/ianc/devel/arm/xen.git/xen' > Makefile:232: recipe for target '/local/scratch/ianc/devel/arm/xen.git/xen/' > failed > make: *** [/local/scratch/ianc/devel/arm/xen.git/xen/] Error 2 > make: Leaving directory '/local/scratch/ianc/devel/arm/xen.git/xen' > E: failed: make -C xen XEN_TARGET_ARCH=arm64 DESTDIR=/tmp/tmpW3nFxB > /local/scratch/ianc/devel/arm/xen.git/xen/ debug=y > CROSS_COMPILE=aarch64-linux-gnu- CONFIG_EARLY_PRINTK=fastmodel install > + rm -rf /tmp/tmpW3nFxB > > Adding -j12 also got another error which I suppose was blocked by the > above: > > aarch64-linux-gnu-gcc -O1 -fno-omit-frame-pointer -g -fno-strict-aliasing > -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement > -Wno-unused-but-set-variable -Wno-unused-local-typedefs > -I/local/scratch/ianc/devel/arm/xen.git/xen/include -fno-stack-protector > -fno-exceptions -Wnested-externs -mcpu=generic -mgeneral-regs-only > -DGCC_HAS_VISIBILITY_ATTRIBUTE -nostdinc -fno-builtin -fno-common -Werror > -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include > /local/scratch/ianc/devel/arm/xen.git/xen/include/xen/config.h > '-D__OBJECT_FILE__="asm-offsets.s"' -fno-optimize-sibling-calls > -DCONFIG_EARLY_PRINTK -DEARLY_PRINTK_INIT_UART > -DEARLY_PRINTK_INC=\"debug-pl011.inc\" -DEARLY_PRINTK_BAUD=115200 > -DEARLY_UART_BASE_ADDRESS=0x1c09 -DEARLY_UART_REG_SHIFT= -DVERBOSE > -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF ./.asm-offsets.s.d -S > -o asm-offsets.s arm64/asm-offsets.c > In file included from :0:0: > /local/scratch/ianc/devel/arm/xen.git/xen/include/xen/config.h:10:32: fatal > error: generated/autoconf.h: No such file or directory > #include > ^ > > Running oldconfig didn't help. > > I'm not sure what's wrong, x86_64 seems to behave the same. > > Ian. > So in an effort to retain the discussion. The first issue appears to be related to the extra path on the command because for this failure to happen objs-y would have been empty. Ian had made some changes to his script and is not unable to reproduce it. The second issue is because the install target does not depend on the build target but instead depends on the same output as the build target. So the rule to generate these files needs to cover the install target. I've submitted a patch that should resolve the issue and will be squashed in on my next repost. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] squash into 'build: use generated Kconfig options for Xen'
On Wed, 2015-12-16 at 05:42 -0600, Doug Goldstein wrote: > Signed-off-by: Doug Goldstein Thanks, with this my build issue has gone away and I can confirm that the same set of .o files are built for arm* and the target file is the same size both before and after this series, which implies to me that the defconfig pretty much matches what we had before, at least to the granularity I can be bothered checking with. Ian. > --- > xen/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/Makefile b/xen/Makefile > index 487eeaa..9023863 100644 > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -33,7 +33,7 @@ default: build > .PHONY: dist > dist: install > > -build:: include/config/auto.conf > +build install:: include/config/auto.conf > > .PHONY: build install uninstall clean distclean cscope TAGS tags MAP > gtags > build install uninstall debug clean distclean cscope TAGS tags MAP > gtags:: ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] build: convert CONFIG_COMPAT to Kconfig
Use the Kconfig generated CONFIG_COMPAT defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein --- config/x86_64.mk | 1 - xen/arch/x86/Kconfig | 1 + xen/common/Kconfig | 7 +++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/config/x86_64.mk b/config/x86_64.mk index f12d549..85fa27c 100644 --- a/config/x86_64.mk +++ b/config/x86_64.mk @@ -2,7 +2,6 @@ CONFIG_X86 := y CONFIG_X86_64 := y CONFIG_X86_$(XEN_OS) := y -CONFIG_COMPAT := y CONFIG_MIGRATE := y CONFIG_XCUTILS := y diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 07e366d..7d2ed96 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -3,6 +3,7 @@ config X86_64 config X86 def_bool y + select COMPAT select HAS_ACPI select HAS_CPUFREQ select HAS_EHCI diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 7d0e9a9..62e5519 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -1,6 +1,13 @@ menu "Common Features" +config COMPAT + def_bool y + help + 32-bit interface support on 64-bit Xen which is used for both + HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective + of the destination runmode of the guest. + # Select HAS_DEVICE_TREE if device tree is supported config HAS_DEVICE_TREE bool -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 28/28] build: convert CONFIG_COMPAT to Kconfig
On 12/15/15 9:23 AM, Jan Beulich wrote: On 15.12.15 at 14:13, wrote: >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -24,6 +24,13 @@ config ARCH_DEFCONFIG >> >> menu "Architecture Features" >> >> +config COMPAT >> +def_bool y >> +help >> + 32-bit interface support on 64-bit Xen which is used for both >> + HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective >> + of the destination runmode of the guest. > > This would really belong in xen/common/Kconfig and be selected by x86. > > Jan > I've sent a replacement patch that I will use for v9. Does that seem acceptable? -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VMX: allocate APIC access page from domain heap
On 16/12/15 07:57, Jan Beulich wrote:
> ... since we don't need its virtual address anywhere (it's a
> placeholder page only after all). For this wo work (and possibly be
"to work"
> done elsewhere too) share_xen_page_with_guest() needs to mark pages
> handed to it as Xen heap ones.
>
> To be on the safe side, also explicitly clear the page (not having done
> so was okay due to the XSA-100 fix, but is still a latent bug since we
> don't formally guarantee allocations to come out zeroed, and in fact
> this property may disappear again as soon as the asynchronous runtime
> scrubbing patches arrive).
>
> Signed-off-by: Jan Beulich
> ---
> Alternatives might be to use a
> - global (or perhaps per-node) page across VMs (on the basis that VMs
> shouldn't be writing into that page anyway)
I am surprised by the concern about a zeroed page, yet not concerned by
sharing this page across VMs.
Even though we can get away with sharing it across VMs, we should
probably avoid it, to be on the safe side. It is only 1 page per VM.
> - fake MFN pointing into nowhere (would need to ensure no side effects
> can occur, like PCIe errors or NMIs)
>
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2402,19 +2402,21 @@ gp_fault:
>
> static int vmx_alloc_vlapic_mapping(struct domain *d)
> {
> -void *apic_va;
> +struct page_info *pg;
> +unsigned long mfn;
>
> if ( !cpu_has_vmx_virtualize_apic_accesses )
> return 0;
>
> -apic_va = alloc_xenheap_page();
> -if ( apic_va == NULL )
> +pg = alloc_domheap_page(d, MEMF_no_owner);
> +if ( !pg )
> return -ENOMEM;
> -share_xen_page_with_guest(virt_to_page(apic_va), d, XENSHARE_writable);
> -d->arch.hvm_domain.vmx.apic_access_mfn = virt_to_mfn(apic_va);
> -set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE),
> - _mfn(virt_to_mfn(apic_va)), PAGE_ORDER_4K,
> - p2m_get_hostp2m(d)->default_access);
> +mfn = page_to_mfn(pg);
> +clear_domain_page(mfn);
> +share_xen_page_with_guest(pg, d, XENSHARE_writable);
> +d->arch.hvm_domain.vmx.apic_access_mfn = mfn;
> +set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE), _mfn(mfn),
> + PAGE_ORDER_4K, p2m_get_hostp2m(d)->default_access);
>
> return 0;
> }
> @@ -2422,8 +2424,16 @@ static int vmx_alloc_vlapic_mapping(stru
> static void vmx_free_vlapic_mapping(struct domain *d)
> {
> unsigned long mfn = d->arch.hvm_domain.vmx.apic_access_mfn;
> +
> if ( mfn != 0 )
> -free_xenheap_page(mfn_to_virt(mfn));
> +{
> +struct page_info *pg = mfn_to_page(mfn);
> +
> +if ( test_and_clear_bit(_PGC_allocated, &pg->count_info) )
> +put_page(pg);
> +clear_bit(_PGC_xen_heap, &pg->count_info);
This is a different teardown procedure to the allocation. Instead, it
would be better to either ASSERT that _PGC_allocated is set, or move the
_PGC_xen_heap change into the if() condition.
~Andrew
> +free_domheap_page(pg);
> +}
> }
>
> static void vmx_install_vlapic_mapping(struct vcpu *v)
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -454,7 +454,7 @@ void share_xen_page_with_guest(
> /* Only add to the allocation list if the domain isn't dying. */
> if ( !d->is_dying )
> {
> -page->count_info |= PGC_allocated | 1;
> +page->count_info |= PGC_xen_heap | PGC_allocated | 1;
> if ( unlikely(d->xenheap_pages++ == 0) )
> get_knownalive_domain(d);
> page_list_add_tail(page, &d->xenpage_list);
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] tools: always enable HAS_MEM_ACCESS
On Tue, 2015-12-15 at 12:11 +, Ian Campbell wrote: > On Fri, 2015-12-11 at 10:00 -0600, Doug Goldstein wrote: > > For all supported targets HAS_MEM_ACCESS is enabled so this drops the > > conditional and always makes it enabled. The goal here is to remove the > > setting in the top level config directory when kconfig changes land. > > > > Signed-off-by: Doug Goldstein > > Acked-by: Ian Campbell and now applied, thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 66401: regressions - FAIL
flight 66401 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/66401/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543 version targeted for testing: ovmf 660aaec3118b0763ee4fcd83b936bf15ffcf23a9 baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z8 days Failing since 65593 2015-12-08 23:44:51 Z7 days5 attempts Testing same since66401 2015-12-15 18:19:16 Z0 days1 attempts People who touched revisions under test: "Yao, Jiewen" Ard Biesheuvel Cecil Sheng Chao Zhang Dandan Bi Daocheng Bu Eric Dong Eugene Cohen Hao Wu Hess Chen Heyi Guo Jaben Carsey Jeff Fan Jiaxin Wu Jordan Justen Laszlo Ersek Leekha Shaveta Michael Kinney Qin Long Qiu Shumin Ruiyu Ni Yao, Jiewen jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1250 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Minios-devel] [PATCH v7 0/] Begin to disentangle libxenctrl and provide some stable libraries
In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some parts of the libxenctrl API/ABI by disaggregating into separate libraries. This is v7 of that set of series against: xen qemu-xen qemu-xen-traditional mini-os NB: Samuel+minios-devel will only get the mini-os side and Stefano+qemu -devel the qemu-xen side. The code for all repos can be found in: git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git v7 git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git v7 git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git v7 git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git v7 The tip of the xen.git branch contains an extra patch hacking Config.mk to point to all the others above, which should get the correct things for the HEAD of the branch, but not further back in time. The new libraries here are: * libxentoollog: Common logging infrastructure * libxenevtchn: Userspace access to evtchns (via /dev/xen/evtchn etc) * libxengnttab: Userspace access to grant tables (via /dev/xen/gnt??? etc) * libxencall: Making hypercalls (i.e. the IOCTL_PRIVCMD_HYPERCALL type functionality) * libxenforeignmemory: Privileged mappings of foreign memory (IOCTL_PRIVCMD_MMAP et al) The first three were actually pretty distinct within libxenctrl already and have not changed in quite some time. Although the other two are somewhat new they are based on top of long standing stable ioctls, which gives me some confidence. Nonetheless I would appreciate extra review of at least the interface headers of all of these with a particular eye to the suitability of these interfaces being maintained in an ABI (_B_, not _P_) stable way going forward. Still to come would be libraries for specific out of tree purposes (device model, kexec), which would be adding new library at the same level as libxc I think, rather than underneath, i.e. also using the libraries split out here, but hopefully not libxenctrl itself. The new libraries use linker version-scripts to hopefully make future ABI changes be possible in a compatible way. Since last time: * Lots more docs updates based on feedback given and especially the discussion around the semantics of the libraries wrt forking without exec. * s/gnttab_munmap/gnttab_unmap/ and s/gntshr_munmap/gntshr_unshare/ in the libxengnttab API. * Use O_CLOEXEC on Linux and FreeBSD unconditionally. * Fixed a stubdom/Makefile build race issue * Dropped -pedantic from headers check, the headers in xen/include/public are not -pedantic clean, and the libraries can include headers from there (and then the check breaks). * Dropped libxencall atform madvise thing, in favour of simpler solution of touching the pages to uncow them. * The xentoollog patch went in but was reverted, that patch now refers to the revisions of qemu and mini-os with the corresponding changes. Even with the dropped acks mini-os and qemu-xen-trad are fully acked, while qemu-xen and xen are mostly acked (but had a few dropped acks since last time). The whole thing has been build tested on Linux (incl stubdoms), and on FreeBSD. I have runtime tested on Linux with qemu-xen, qemu-xen-trad and stubdoms. Neither NetBSD nor Solaris have been tested at all. It's certainly not impossible that I've not got the #includes in the new files quite right. http://xenbits.xen.org/people/ianc/libxenctrl-split/v7.html is the document I've been using to try and track what I'm doing. It may not be all that useful. The history of it is in the v6-with-doc branch of the xen.git linked to above. A few of the initial patches went in, but in the meantime I discovered a wrinkle in the changes to the stubdom build changes, so now there are some new ones. tools: Refactor "xentoollog" into its own library went in but then came out again and is now blocking on a libvirt patch, which is in libvirt.git#master waiting to get through our libvirt push gate. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 05/29] tools: Arrange to check public headers for ANSI compatiblity
Using the same rune as we use for the Xen public headers, except we do not need stdint.h here. Signed-off-by: Ian Campbell Acked-by: Wei Liu --- v7: Drop -pendantic: Some library headers include parts of xen/include/public, which in turn are not -pedantic clean Retained ack, hope that's ok. --- .gitignore | 2 ++ tools/Rules.mk | 8 tools/libs/evtchn/Makefile | 4 +++- tools/libs/toollog/Makefile | 5 - 4 files changed, 17 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index bf382e5..b34dc3c 100644 --- a/.gitignore +++ b/.gitignore @@ -86,6 +86,8 @@ tools/config.cache config/Tools.mk config/Stubdom.mk config/Docs.mk +tools/libs/toollog/headers.chk +tools/libs/evtchn/headers.chk tools/blktap2/daemon/blktapctrl tools/blktap2/drivers/img2qcow tools/blktap2/drivers/lock-util diff --git a/tools/Rules.mk b/tools/Rules.mk index 75d02c4..0c83e22 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -176,6 +176,14 @@ INSTALL_PYTHON_PROG = \ %.opic: %.S $(CC) $(CPPFLAGS) -DPIC $(CFLAGS) $(CFLAGS.opic) -fPIC -c -o $@ $< $(APPEND_CFLAGS) +headers.chk: + for i in $(filter %.h,$^); do \ + $(CC) -x c -ansi -Wall -Werror $(CFLAGS_xeninclude) \ + -S -o /dev/null $$i || exit 1; \ + echo $$i; \ + done >$@.new + mv $@.new $@ + subdirs-all subdirs-clean subdirs-install subdirs-distclean: .phony @set -e; for subdir in $(SUBDIRS) $(SUBDIRS-y); do \ $(MAKE) subdir-$(patsubst subdirs-%,%,$@)-$$subdir; \ diff --git a/tools/libs/evtchn/Makefile b/tools/libs/evtchn/Makefile index 85ed6dc..892892c 100644 --- a/tools/libs/evtchn/Makefile +++ b/tools/libs/evtchn/Makefile @@ -32,8 +32,9 @@ build: $(MAKE) libs .PHONY: libs -libs: $(LIB) +libs: headers.chk $(LIB) +headers.chk: $(wildcard include/*.h) libxenevtchn.a: $(LIB_OBJS) $(AR) rc $@ $^ @@ -63,3 +64,4 @@ TAGS: .PHONY: clean clean: rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS) + rm -f headers.chk diff --git a/tools/libs/toollog/Makefile b/tools/libs/toollog/Makefile index bd12403..72c70c9 100644 --- a/tools/libs/toollog/Makefile +++ b/tools/libs/toollog/Makefile @@ -27,7 +27,9 @@ build: $(MAKE) libs .PHONY: libs -libs: $(LIB) +libs: headers.chk $(LIB) + +headers.chk: $(wildcard include/*.h) libxentoollog.a: $(LIB_OBJS) $(AR) rc $@ $^ @@ -57,3 +59,4 @@ TAGS: .PHONY: clean clean: rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS) + rm -f headers.chk -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 00/29] Begin to disentangle libxenctrl and provide some stable libraries
We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.
This is the xen part of the first phase of that change.
This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.
Ian Campbell (29):
stubdom: recurse into tools/include in mk-headers-$(XEN_TARGET_ARCH)
rule
tools: Refactor "xentoollog" into its own library
tools/libxc: Remove osdep indirection for xc_evtchn
tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
tools: Arrange to check public headers for ANSI compatiblity
tools/libxc: Remove osdep indirection for xc_gnt{shr,tab}
tools: Refactor /dev/xen/gnt{dev,shr} wrappers into libxengnttab.
tools/libxc: Remove osdep indirection for privcmd
tools: Refactor hypercall calling wrappers into libxencall.
tools/libxc: drop xc_map_foreign_bulk_compat wrappers
tools: Remove xc_map_foreign_batch
tools: Implement xc_map_foreign_range(s) in terms of common helper
tools: Refactor foreign memory mapping into libxenforeignmemory
tools/libs/foreignmemory: provide xenforeignmemory_unmap.
tools/libs/foreignmemory: use size_t for size arguments.
tools/libs/foreignmemory: Mention restrictions on fork in docs.
tools/libs/foreignmemory: Support err == NULL to map.
tools/libs/foreignmemory: pull array length argument to map forward
tools/libs/evtchn: Review and update doc comments.
tools/libs: Clean up hard tabs.
tools/libs/gnttab: Extensive updates to API documentation.
tools/libs/call: Update some log messages to not refer to xc.
tools/libs/call: Describe return values and error semantics for
xencall*
tools/libs/call: Avoid xc_memalign in netbsd and solaris backends
tools/libs/call: linux: touch newly allocated pages after madvise
lockdown
tools/libs/{call,evtchn}: Document requirements around forking.
tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD
tools: Update CFLAGS for qemu-xen to allow it to use new libraries
HACK: Update Config.mk to pull all the right bits from my xenbits
trees
.gitignore | 10 +
Config.mk | 24 +-
config/FreeBSD.mk | 2 -
config/NetBSD.mk | 3 -
config/NetBSDRump.mk | 1 -
config/StdGNU.mk | 1 -
config/SunOS.mk| 1 -
stubdom/Makefile | 87 +-
stubdom/grub/Makefile | 1 +
tools/Makefile | 18 +-
tools/Rules.mk | 54 +-
tools/console/Makefile | 3 +-
tools/console/daemon/io.c | 64 +-
tools/console/daemon/utils.c | 1 -
tools/console/daemon/utils.h | 1 +
tools/libs/Makefile| 11 +
tools/libs/call/Makefile | 67 ++
tools/libs/call/buffer.c | 192 +
tools/libs/call/core.c | 147
tools/libs/call/freebsd.c | 126 +++
tools/libs/call/include/xencall.h | 127 +++
tools/libs/call/libxencall.map | 19 +
tools/libs/call/linux.c| 134 +++
tools/libs/call/minios.c | 81 ++
tools/libs/call/netbsd.c | 121 +++
tools/libs/call/private.h | 68 ++
tools/libs/call/solaris.c | 97 +++
tools/libs/evtchn/Makefile | 67 ++
tools/libs/evtchn/core.c | 72 ++
tools/libs/evtchn/freebsd.c| 138
tools/libs/evtchn/include/xenevtchn.h | 163
tools/libs/evtchn/libxenevtchn.map | 14 +
tools/libs/evtchn/linux.c | 140
tools/libs/evtchn/minios.c | 266 ++
tools/libs/evtchn/netbsd.c | 147
tools/libs/evtchn/private.h| 25 +
tools/libs/evtchn/solaris.c| 135 +++
tools/libs/foreignmemory/Makefile | 67 ++
tools/libs/foreignmemory/compat.c | 72 ++
tools/libs/foreignmemory/core.c| 116 +++
tools/libs/foreignmemory/freebsd.c | 115 +++
.../libs/foreignmemory/include/xenforeignmemory.h | 128 +++
tools/libs/foreignmemory/libxenforeignmemory.map | 8 +
tools/libs/foreignmemory/linux.c | 283 +++
tools/libs/foreignmemory/minios.c | 69 ++
tools/libs/foreignmemory/netbsd.c | 111 +++
tools/libs/foreignmemory
[Xen-devel] [PATCH XEN v7 01/29] stubdom: recurse into tools/include in mk-headers-$(XEN_TARGET_ARCH) rule
... rather than in the libxc rule. This puts all the header dependencies in one place and will allow us to avoid races when more libraries which need these headers are introduced. I observed issues with the xen-foreign/tmp.size file getting deleted in parallel with another process trying to use it. The mini-os links are already created in the mk-headers-$(XEN_TARGET_ARCH) target so the other places which do so are redundant, in the case of polarssl and vtpmmgr indirectly through their eventual dependency on newlib which in turn depends on mk-headers-$(XEN_TARGET_ARCH). Signed-off-by: Ian Campbell Cc: samuel.thiba...@ens-lyon.org --- v7: New patch. --- stubdom/Makefile | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/stubdom/Makefile b/stubdom/Makefile index e1359cf..fd84024 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -304,6 +304,7 @@ ioemu/linkfarm.stamp: endif mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET) + $(MAKE) -C $(XEN_ROOT)/tools/include mkdir -p include/xen && \ ln -sf $(wildcard $(XEN_ROOT)/xen/include/public/*.h) include/xen && \ ln -sf $(addprefix $(XEN_ROOT)/xen/include/public/,arch-x86 hvm io xsm) include/xen && \ @@ -341,9 +342,7 @@ $(TARGETS_MINIOS): mini-os-%: .PHONY: libxc libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a -libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib - $(MAKE) -C $(XEN_ROOT)/tools/include - $(MAKE) DESTDIR= -C $(MINI_OS) links +libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: mk-headers-$(XEN_TARGET_ARCH) cross-zlib CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) DESTDIR= CONFIG_LIBXC_MINIOS=y -C libxc-$(XEN_TARGET_ARCH) libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a @@ -386,7 +385,6 @@ c: $(CROSS_ROOT) .PHONY: vtpm vtpm: cross-polarssl cross-tpmemu - make -C $(MINI_OS) links XEN_TARGET_ARCH="$(XEN_TARGET_ARCH)" CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) -C $@ ## @@ -395,7 +393,6 @@ vtpm: cross-polarssl cross-tpmemu .PHONY: vtpmmgr vtpmmgr: cross-polarssl - make -C $(MINI_OS) links XEN_TARGET_ARCH="$(XEN_TARGET_ARCH)" CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(MAKE) -C $@ ## -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 03/29] tools/libxc: Remove osdep indirection for xc_evtchn
The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.
Note that the intention is to move this into a separate library
shortly.
Nested virt probably suffices for this use case now.
One incorrect instance of using xc_interface where xc_evtchn (in ocaml
stubs) is removed, this used to work because they were typedefs to the
same struct, but is no longer permitted.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/include/xenctrlosdep.h| 16 -
tools/libxc/xc_evtchn.c | 45 --
tools/libxc/xc_freebsd_osdep.c| 79
tools/libxc/xc_linux_osdep.c | 76 +--
tools/libxc/xc_minios.c | 63 ---
tools/libxc/xc_netbsd.c | 72 --
tools/libxc/xc_private.c | 37 +---
tools/libxc/xc_private.h | 17 ++
tools/libxc/xc_solaris.c | 71 --
tools/libxc/xenctrl_osdep_ENOSYS.c| 87 ---
tools/ocaml/libs/eventchn/xeneventchn_stubs.c | 4 +-
12 files changed, 180 insertions(+), 389 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 01a6dda..881dcd5 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -117,7 +117,7 @@
*/
typedef struct xc_interface_core xc_interface;
-typedef struct xc_interface_core xc_evtchn;
+typedef struct xenevtchn_handle xc_evtchn;
typedef struct xc_interface_core xc_gnttab;
typedef struct xc_interface_core xc_gntshr;
diff --git a/tools/libxc/include/xenctrlosdep.h
b/tools/libxc/include/xenctrlosdep.h
index 5121d9b..89564e1 100644
--- a/tools/libxc/include/xenctrlosdep.h
+++ b/tools/libxc/include/xenctrlosdep.h
@@ -51,7 +51,6 @@
enum xc_osdep_type {
XC_OSDEP_PRIVCMD,
-XC_OSDEP_EVTCHN,
XC_OSDEP_GNTTAB,
XC_OSDEP_GNTSHR,
};
@@ -90,21 +89,6 @@ struct xc_osdep_ops
int nentries);
} privcmd;
struct {
-int (*fd)(xc_evtchn *xce, xc_osdep_handle h);
-
-int (*notify)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
port);
-
-evtchn_port_or_error_t (*bind_unbound_port)(xc_evtchn *xce,
xc_osdep_handle h, int domid);
-evtchn_port_or_error_t (*bind_interdomain)(xc_evtchn *xce,
xc_osdep_handle h, int domid,
- evtchn_port_t
remote_port);
-evtchn_port_or_error_t (*bind_virq)(xc_evtchn *xce,
xc_osdep_handle h, unsigned int virq);
-
-int (*unbind)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
port);
-
-evtchn_port_or_error_t (*pending)(xc_evtchn *xce, xc_osdep_handle
h);
-int (*unmask)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
port);
-} evtchn;
-struct {
#define XC_GRANT_MAP_SINGLE_DOMAIN 0x1
void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count, int flags, int prot,
diff --git a/tools/libxc/xc_evtchn.c b/tools/libxc/xc_evtchn.c
index 15f0580..ae2fe1a 100644
--- a/tools/libxc/xc_evtchn.c
+++ b/tools/libxc/xc_evtchn.c
@@ -77,51 +77,6 @@ int xc_evtchn_status(xc_interface *xch, xc_evtchn_status_t
*status)
sizeof(*status), 1);
}
-int xc_evtchn_fd(xc_evtchn *xce)
-{
-return xce->ops->u.evtchn.fd(xce, xce->ops_handle);
-}
-
-int xc_evtchn_notify(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.notify(xce, xce->ops_handle, port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_unbound_port(xc_evtchn *xce, int domid)
-{
-return xce->ops->u.evtchn.bind_unbound_port(xce, xce->ops_handle, domid);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_interdomain(xc_evtchn *xce, int domid,
- evtchn_port_t remote_port)
-{
-return xce->ops->u.evtchn.bind_interdomain(xce, xce->ops_handle, domid,
remote_port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_virq(xc_evtchn *xce, unsigned int virq)
-{
-return xce->ops->u.evtchn.bind_virq(xce, xce->ops_handle, virq);
-}
-
-int xc_evtchn_unbind(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.unbind(xce, xce->ops_handle, port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_pending(xc_evtchn *xce)
-{
-return xce->ops->u.evtchn.pending(xce, xce->ops_handle);
-}
-
-int xc_evtchn_unmask(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.unmask(xce, xce->ops_handle, port);
-}
-
/*
* Local variables:
* mode: C
diff --git a/tools/libxc/xc_freebsd_osdep.c b/tools/libxc/xc_freebsd_osdep.c
index 4d31a1e..4323e16 100644
--- a/tools/libxc/xc_freebsd_osdep.c
+++ b/tools/libxc/xc_freebsd_osde
[Xen-devel] [PATCH XEN v7 06/29] tools/libxc: Remove osdep indirection for xc_gnt{shr, tab}
The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.
Nested virt probably suffices for this use case now.
It is now necessary to provide explicit versions of things for
platforms which do not implement this functionality, since the osdep
dispatcher cannot fulfil this need any more. These are provided by
appropriate xc_nognt???.c files which are compiled and linked on the
appropriate platforms. In them open and close return failure and
everything else aborts, since if open fails they should never be
called.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libxc/Makefile | 10 ++--
tools/libxc/include/xenctrl.h | 4 +-
tools/libxc/include/xenctrlosdep.h | 23 ---
tools/libxc/xc_gnttab.c| 57 --
tools/libxc/xc_linux_osdep.c | 119 +++--
tools/libxc/xc_minios.c| 51 ++--
tools/libxc/xc_nogntshr.c | 46 ++
tools/libxc/xc_nognttab.c | 50
tools/libxc/xc_private.c | 83 +-
tools/libxc/xc_private.h | 24
10 files changed, 274 insertions(+), 193 deletions(-)
create mode 100644 tools/libxc/xc_nogntshr.c
create mode 100644 tools/libxc/xc_nognttab.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b8fc6a5..184cbb7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -43,11 +43,11 @@ CTRL_SRCS-y += xc_resource.c
CTRL_SRCS-$(CONFIG_X86) += xc_psr.c
CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
-CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
-CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
-CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c xc_nognttab.c
xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_nogntshr.c
CTRL_SRCS-y += xc_evtchn_compat.c
GUEST_SRCS-y :=
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 8f31c4d..0fc2a11 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -117,8 +117,8 @@
*/
typedef struct xc_interface_core xc_interface;
-typedef struct xc_interface_core xc_gnttab;
-typedef struct xc_interface_core xc_gntshr;
+typedef struct xengntdev_handle xc_gnttab;
+typedef struct xengntdev_handle xc_gntshr;
enum xc_error_code {
XC_ERROR_NONE = 0,
diff --git a/tools/libxc/include/xenctrlosdep.h
b/tools/libxc/include/xenctrlosdep.h
index 89564e1..423660d 100644
--- a/tools/libxc/include/xenctrlosdep.h
+++ b/tools/libxc/include/xenctrlosdep.h
@@ -51,8 +51,6 @@
enum xc_osdep_type {
XC_OSDEP_PRIVCMD,
-XC_OSDEP_GNTTAB,
-XC_OSDEP_GNTSHR,
};
/* Opaque handle internal to the backend */
@@ -88,27 +86,6 @@ struct xc_osdep_ops
size_t chunksize, privcmd_mmap_entry_t
entries[],
int nentries);
} privcmd;
-struct {
-#define XC_GRANT_MAP_SINGLE_DOMAIN 0x1
-void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h,
- uint32_t count, int flags, int prot,
- uint32_t *domids, uint32_t *refs,
- uint32_t notify_offset,
- evtchn_port_t notify_port);
-int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h,
- void *start_address,
- uint32_t count);
-int (*set_max_grants)(xc_gnttab *xcg, xc_osdep_handle h, uint32_t
count);
-} gnttab;
-struct {
-void *(*share_pages)(xc_gntshr *xcg, xc_osdep_handle h,
- uint32_t domid, int count,
- uint32_t *refs, int writable,
- uint32_t notify_offset,
- evtchn_port_t notify_port);
-int (*munmap)(xc_gntshr *xcg, xc_osdep_handle h,
- void *start_address, uint32_t count);
-} gntshr;
} u;
};
typedef struct xc_osdep_ops xc_osdep_ops;
diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c
index 60335d8..a51f405 100644
--- a/tools/libxc/xc_gnttab.c
+++ b/tools/libxc/xc_gnttab.c
@@ -143,68 +143,48 @@ grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface
*xch, int domid,
return _gnttab_map_table(xch, domid, gnt_num);
}
-void *xc_gnttab_map_grant_ref(xc_gnttab *xcg,
+void *xc_gnttab_map_grant_ref(xc_gnt
[Xen-devel] [PATCH XEN v7 17/29] tools/libs/foreignmemory: Support err == NULL to map.
The existing xc_map_foreign_bulk-like interface encourages callers to
miss error checking for partial failure (by forgetting to scan the err
array).
Add support for passing err==NULL which behaves in a
xc_map_foreign_pages-like manner and returns a global error for any
failure.
While documenting this also clarify the overall behaviour and the
behaviour with err!=NULL.
With this the compat wrapper of xc_map_foreign_pages() can be
simplified.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
Acked-by: Ian Jackson
---
v7: Check for NULL when allocating err.
v6: New
---
tools/libs/foreignmemory/core.c| 33 +-
.../libs/foreignmemory/include/xenforeignmemory.h | 24 ++--
tools/libxc/xc_foreign_memory.c| 22 +--
3 files changed, 54 insertions(+), 25 deletions(-)
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index 21dc7ee..4e0541f 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -14,6 +14,8 @@
*/
#include
+#include
+#include
#include "private.h"
@@ -64,7 +66,36 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
const xen_pfn_t *arr, int *err, size_t num)
{
-return osdep_xenforeignmemory_map(fmem, dom, prot, arr, err, num);
+void *ret;
+int *err_to_free = NULL;
+
+if ( err == NULL )
+err = err_to_free = malloc(num * sizeof(int));
+
+if ( err == NULL )
+return NULL;
+
+ret = osdep_xenforeignmemory_map(fmem, dom, prot, arr, err, num);
+
+if ( ret == 0 && err_to_free )
+{
+int i;
+
+for ( i = 0 ; i < num ; i++ )
+{
+if ( err[i] )
+{
+errno = -err[i];
+(void)osdep_xenforeignmemory_unmap(fmem, ret, num);
+ret = NULL;
+break;
+}
+}
+}
+
+free(err_to_free);
+
+return ret;
}
int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 36f3753..b162dca 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -80,10 +80,28 @@ int xenforeignmemory_close(xenforeignmemory_handle *xmem);
*
* prot is as for mmap(2).
*
- * Can partially succeed. When a page cannot be mapped, its respective
- * field in @err is set to the corresponding errno value.
+ * @arr is an array of @pages gfns to be mapped linearly in the local
+ * address range. @err is an (optional) output array used to report
+ * per-page errors, as errno values.
*
- * Returns NULL if no pages can be mapped.
+ * If @err is given (is non-NULL) then the mapping may partially
+ * succeed and return a valid pointer while also using @err to
+ * indicate the success (0) or failure (errno value) of the individual
+ * pages. The global errno thread local variable is not valid in this
+ * case.
+ *
+ * If @err is not given (is NULL) then on failure to map any page any
+ * successful mappings will be undone and NULL will be returned. errno
+ * will be set to correspond to the first failure (which may not be
+ * the most critical).
+ *
+ * It is also possible to return NULL due to a complete failure,
+ * i.e. failure to even attempt the mapping, in this case the global
+ * errno will have been set and the contents of @err (if given) is
+ * invalid.
+ *
+ * Note that it is also possible to return non-NULL with the contents
+ * of @err indicating failure to map every page.
*/
void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 1737c10..4b24388 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -23,32 +23,12 @@
void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, int prot,
const xen_pfn_t *arr, int num)
{
-void *res;
-int i, *err;
-
if (num < 0) {
errno = EINVAL;
return NULL;
}
-err = malloc(num * sizeof(*err));
-if (!err)
-return NULL;
-
-res = xenforeignmemory_map(xch->fmem, dom, prot, arr, err, num);
-if (res) {
-for (i = 0; i < num; i++) {
-if (err[i]) {
-errno = -err[i];
-munmap(res, num * PAGE_SIZE);
-res = NULL;
-break;
-}
-}
-}
-
-free(err);
-return res;
+return xenforeignmemory_map(xch->fmem, dom, prot, arr, NULL, num);
}
void *xc_map_foreign_range(xc_interface *xch,
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-deve
[Xen-devel] [PATCH XEN v7 19/29] tools/libs/evtchn: Review and update doc comments.
Remove the reference to pre-4.1, since this is now a new library. Fixup references to xc. Signed-off-by: Ian Campbell Acked-by: Wei Liu Acked-by: Ian Jackson --- tools/libs/evtchn/include/xenevtchn.h | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/tools/libs/evtchn/include/xenevtchn.h b/tools/libs/evtchn/include/xenevtchn.h index 3380fa3..60da2a3 100644 --- a/tools/libs/evtchn/include/xenevtchn.h +++ b/tools/libs/evtchn/include/xenevtchn.h @@ -46,11 +46,9 @@ typedef struct xentoollog_logger xentoollog_logger; * which case errno will be set appropriately. * * Note: - * After fork a child process must not use any opened xc evtchn + * After fork a child process must not use any opened evtchn * handle inherited from their parent. They must open a new handle if - * they want to interact with xc. - * - * Before Xen pre-4.1 this function would sometimes report errors with perror. + * they want to interact with evtchn. */ /* Currently no flags are defined */ xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned open_flags); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 11/29] tools: Remove xc_map_foreign_batch
It can trivially be replaced by xc_map_foreign_pages which is the
interface I want to move to going forward (by standardising on _bulk
but handling err=NULL as _pages does).
The callers of _batch are checking a mixture of a NULL return or
looking to see if the top nibble of the (usually sole) mfn they pass
has been modified to be non-zero to detect errors. _pages never
modifies the mfn it was given (it's const) and returns NULL on
failure, so adjust the error handling where necessary. Some callers
use a copy of the mfn array, for reuse on failure with _batch, which
is no longer necessary as _pages doesn't modify the array, however I
haven't cleaned that up here.
This reduces the twist maze of xc_map_foreign_* by one, which will be
useful when trying to come up with an underlying stable interface.
NetBSD and Solaris implemented xc_map_foreign_bulk in terms of
xc_map_foreign_batch via a compat layer, so xc_map_foreign_batch
becomes an internal osdep for them.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
Acked-by: George Dunlap
Cc: George Dunlap
---
v7: Don't mention new ports implementing _bulk, which is confusing and
will be obsolete a couple of patches later.
v6: Switch to xc_map_foreign_pages not xc_map_foreign_bulk, since the
former has more similar error handling semantics to the current
usage.
Dropped acks.
---
tools/libxc/include/xenctrl.h | 10 ---
tools/libxc/xc_foreign_memory.c | 4 ++-
tools/libxc/xc_linux_osdep.c| 59 +++--
tools/libxc/xc_minios.c | 22 ---
tools/libxc/xc_netbsd.c | 10 +++
tools/libxc/xc_solaris.c| 6 ++---
tools/libxc/xc_vm_event.c | 18 ++---
tools/xenmon/xenbaked.c | 12 -
tools/xenpaging/xenpaging.c | 14 +-
tools/xentrace/xentrace.c | 3 ++-
10 files changed, 48 insertions(+), 110 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 78400d3..cb41c07 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1387,16 +1387,6 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t
dom, int prot,
const xen_pfn_t *arr, int num );
/**
- * DEPRECATED - use xc_map_foreign_bulk() instead.
- *
- * Like xc_map_foreign_pages(), except it can succeeed partially.
- * When a page cannot be mapped, its PFN in @arr is or'ed with
- * 0xF000 to indicate the error.
- */
-void *xc_map_foreign_batch(xc_interface *xch, uint32_t dom, int prot,
- xen_pfn_t *arr, int num );
-
-/**
* Like xc_map_foreign_pages(), except it can succeed partially.
* When a page cannot be mapped, its respective field in @err is
* set to the corresponding errno value.
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index b205bca..2413e75 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -55,6 +55,8 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom,
int prot,
* just implement xc_map_foreign_bulk.
*/
#if defined(__NetBSD__) || defined(__sun__)
+void *osdep_map_foreign_batch(xc_interface *xch, uint32_t dom, int prot,
+ xen_pfn_t *arr, int num );
void *xc_map_foreign_bulk(xc_interface *xch,
uint32_t dom, int prot,
const xen_pfn_t *arr, int *err, unsigned int num)
@@ -75,7 +77,7 @@ void *xc_map_foreign_bulk(xc_interface *xch,
}
memcpy(pfn, arr, num * sizeof(*arr));
-ret = xc_map_foreign_batch(xch, dom, prot, pfn, num);
+ret = osdep_map_foreign_batch(xch, dom, prot, pfn, num);
if (ret) {
for (i = 0; i < num; ++i)
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index e68c495..39c88ce 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -91,8 +91,8 @@ int osdep_privcmd_close(xc_interface *xch)
return close(fd);
}
-static int xc_map_foreign_batch_single(int fd, uint32_t dom,
- xen_pfn_t *mfn, unsigned long addr)
+static int map_foreign_batch_single(int fd, uint32_t dom,
+xen_pfn_t *mfn, unsigned long addr)
{
privcmd_mmapbatch_t ioctlx;
int rc;
@@ -113,59 +113,6 @@ static int xc_map_foreign_batch_single(int fd, uint32_t
dom,
return rc;
}
-void *xc_map_foreign_batch(xc_interface *xch,
- uint32_t dom, int prot,
- xen_pfn_t *arr, int num)
-{
-int fd = xch->privcmdfd;
-privcmd_mmapbatch_t ioctlx;
-void *addr;
-int rc;
-
-addr = mmap(NULL, num << XC_PAGE_SHIFT, prot, MAP_SHARED, fd, 0);
-if ( addr == MAP_FAILED )
-{
-PERROR("xc_map_foreign_batch: mmap failed");
-return NULL;
-}
-
-ioctlx.num = num;
-ioctlx.dom = dom;
-ioctlx.addr = (unsigned long)addr;
-ioctlx.arr = arr;
-
-
[Xen-devel] [PATCH XEN v7 08/29] tools/libxc: Remove osdep indirection for privcmd
The alternative backend (a xen-api/xapi shim) is no longer around and so this stuff is now just baggage which is getting in the way of refactoring libxenctrl. Nested virt probably suffices for this use case now. This was the last component of the osdep infrastructure, so all the dynamic loading etc stuff all falls away too. As part of this I was forced to investigate the twisty xc_map_foreign_* maze, which I have added to the toolstack-library-apis doc in the hopes of doing something sensible. NetBSD and Solaris now call xc_map_foreign_bulk_compat directly from their xc_map_foreign_bulk, which could have been achieved by using some ifdefs around a renamed function. This will fall out in the wash when these functions move to their own library. Signed-off-by: Ian Campbell Acked-by: David Scott Acked-by: Wei Liu --- v7: Stop CCing Dave's dead citrix address. --- config/FreeBSD.mk | 2 - config/NetBSD.mk| 3 - config/NetBSDRump.mk| 1 - config/StdGNU.mk| 1 - config/SunOS.mk | 1 - tools/libxc/Makefile| 27 ++ tools/libxc/include/xenctrl.h | 9 -- tools/libxc/include/xenctrlosdep.h | 133 --- tools/libxc/xc_foreign_memory.c | 31 +-- tools/libxc/xc_freebsd_osdep.c | 100 ++--- tools/libxc/xc_hcall_buf.c | 6 +- tools/libxc/xc_linux_osdep.c| 88 ++ tools/libxc/xc_minios.c | 82 + tools/libxc/xc_netbsd.c | 90 +++ tools/libxc/xc_private.c| 174 ++-- tools/libxc/xc_private.h| 19 ++-- tools/libxc/xc_solaris.c| 90 +++ tools/libxc/xenctrl_osdep_ENOSYS.c | 123 - tools/ocaml/libs/xc/xenctrl.ml | 2 - tools/ocaml/libs/xc/xenctrl.mli | 1 - tools/ocaml/libs/xc/xenctrl_stubs.c | 7 -- tools/ocaml/xenstored/domains.ml| 6 +- tools/ocaml/xenstored/xenstored.ml | 5 +- 23 files changed, 178 insertions(+), 823 deletions(-) delete mode 100644 tools/libxc/include/xenctrlosdep.h delete mode 100644 tools/libxc/xenctrl_osdep_ENOSYS.c diff --git a/config/FreeBSD.mk b/config/FreeBSD.mk index 5a13d607..bb3a5d0 100644 --- a/config/FreeBSD.mk +++ b/config/FreeBSD.mk @@ -1,6 +1,4 @@ include $(XEN_ROOT)/config/StdGNU.mk -DLOPEN_LIBS = - # No wget on FreeBSD base system WGET = ftp diff --git a/config/NetBSD.mk b/config/NetBSD.mk index 21318d6..cf766e5 100644 --- a/config/NetBSD.mk +++ b/config/NetBSD.mk @@ -1,6 +1,3 @@ include $(XEN_ROOT)/config/StdGNU.mk -# Override settings for this OS -DLOPEN_LIBS = - WGET = ftp diff --git a/config/NetBSDRump.mk b/config/NetBSDRump.mk index 2a87218..74755a1 100644 --- a/config/NetBSDRump.mk +++ b/config/NetBSDRump.mk @@ -1,6 +1,5 @@ include $(XEN_ROOT)/config/StdGNU.mk -DLOPEN_LIBS = PTHREAD_LIBS = WGET = ftp diff --git a/config/StdGNU.mk b/config/StdGNU.mk index 129d5c8..39d36b2 100644 --- a/config/StdGNU.mk +++ b/config/StdGNU.mk @@ -31,7 +31,6 @@ DEBUG_DIR ?= /usr/lib/debug SOCKET_LIBS = UTIL_LIBS = -lutil -DLOPEN_LIBS = -ldl SONAME_LDFLAG = -soname SHLIB_LDFLAGS = -shared diff --git a/config/SunOS.mk b/config/SunOS.mk index db5e898..86a384d 100644 --- a/config/SunOS.mk +++ b/config/SunOS.mk @@ -27,7 +27,6 @@ SunOS_LIBDIR_x86_64 = /usr/sfw/lib/amd64 SOCKET_LIBS = -lsocket PTHREAD_LIBS = -lpthread UTIL_LIBS = -DLOPEN_LIBS = -ldl SONAME_LDFLAG = -h SHLIB_LDFLAGS = -R $(SunOS_LIBDIR) -shared diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index 33d18db..3305fdd 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -101,8 +101,6 @@ GUEST_SRCS-y += xc_dom_decompress_unsafe_lzo1x.c GUEST_SRCS-y += xc_dom_decompress_unsafe_xz.c endif -OSDEP_SRCS-y += xenctrl_osdep_ENOSYS.c - -include $(XEN_TARGET_ARCH)/Makefile CFLAGS += -Werror -Wmissing-prototypes @@ -121,11 +119,8 @@ CTRL_PIC_OBJS := $(patsubst %.c,%.opic,$(CTRL_SRCS-y)) GUEST_LIB_OBJS := $(patsubst %.c,%.o,$(GUEST_SRCS-y)) GUEST_PIC_OBJS := $(patsubst %.c,%.opic,$(GUEST_SRCS-y)) -OSDEP_LIB_OBJS := $(patsubst %.c,%.o,$(OSDEP_SRCS-y)) -OSDEP_PIC_OBJS := $(patsubst %.c,%.opic,$(OSDEP_SRCS-y)) - -$(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) $(OSDEP_LIB_OBJS) \ -$(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS) $(OSDEP_PIC_OBJS) : CFLAGS += -include $(XEN_ROOT)/tools/config.h +$(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) \ +$(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h $(CTRL_LIB_OBJS) $(CTRL_PIC_OBJS): CFLAGS += $(CFLAGS_libxengnttab) $(CFLAGS_libxengntshr) @@ -139,17 +134,13 @@ ifneq ($(nosharedlibs),y) LIB += libxenguest.so libxenguest.so.$(MAJOR) libxenguest.so.$(MAJOR).$(MINOR) endif -ifneq ($(nosharedlibs),y) -LIB += xenctrl_osdep_ENOSYS.so -endif - genpath-target = $(call buildmakevars2header,_paths.h
[Xen-devel] [PATCH XEN v7 14/29] tools/libs/foreignmemory: provide xenforeignmemory_unmap.
And require it be used instead of direct munmap.
This will allow e.g. Valgrind hooks to help track incorrect use of
foreign mappings.
Switch all uses of xenforeignmemory_map to use
xenforeignmemory_unmap, not that foreign mappings via the libxc compat
xc_map_foreign_* interface will not take advantage of this and will
need converting.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
Acked-by: Ian Jackson
---
v4: xenforeignmemory_unmap takes pages not bytes, adjust callers.
v6: Document error behaviour
Use an osdep layer, although there is no current need for common
code on _unmap there is for _map so use this indirection for
consistency.
---
tools/libs/foreignmemory/freebsd.c | 6 ++
tools/libs/foreignmemory/include/xenforeignmemory.h | 11 +--
tools/libs/foreignmemory/libxenforeignmemory.map| 1 +
tools/libs/foreignmemory/linux.c| 6 ++
tools/libs/foreignmemory/minios.c | 6 ++
tools/libs/foreignmemory/netbsd.c | 6 ++
tools/libs/foreignmemory/solaris.c | 6 ++
tools/libxc/xc_sr_restore.c | 2 +-
tools/libxc/xc_sr_save.c| 2 +-
tools/libxc/xc_vm_event.c | 2 +-
10 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/tools/libs/foreignmemory/freebsd.c
b/tools/libs/foreignmemory/freebsd.c
index 4b2815d..3c3ad09 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -118,6 +118,12 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle
*fmem,
return addr;
}
+int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+ void *addr, unsigned int num)
+{
+ return munmap(addr, num << PAGE_SHIFT);
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 0909585..b1cae30 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -44,8 +44,8 @@ int xenforeignmemory_close(xenforeignmemory_handle *xmem);
/*
* Maps a range within one domain to a local address range. Mappings
- * should be unmapped with munmap and should follow the same rules as mmap
- * regarding page alignment.
+ * must be unmapped with xenforeignmemory_unmap and should follow the
+ * same rules as mmap regarding page alignment.
*
* prot is as for mmap(2).
*
@@ -57,6 +57,13 @@ int xenforeignmemory_close(xenforeignmemory_handle *xmem);
void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
unsigned int num);
+/*
+ * Unmap a mapping previous created with xenforeignmemory_map().
+ *
+ * Returns 0 on success on failure sets errno and returns -1.
+ */
+int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+ void *addr, unsigned int num);
#endif
diff --git a/tools/libs/foreignmemory/libxenforeignmemory.map
b/tools/libs/foreignmemory/libxenforeignmemory.map
index 11f0d2b..df206b3 100644
--- a/tools/libs/foreignmemory/libxenforeignmemory.map
+++ b/tools/libs/foreignmemory/libxenforeignmemory.map
@@ -3,5 +3,6 @@ VERS_1.0 {
xenforeignmemory_open;
xenforeignmemory_close;
xenforeignmemory_map;
+ xenforeignmemory_unmap;
local: *; /* Do not expose anything by default */
};
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index b403ca7..40ecd41 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -282,6 +282,12 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle
*fmem,
return addr;
}
+int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+ void *addr, unsigned int num)
+{
+return munmap(addr, (unsigned long)num << PAGE_SHIFT);
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libs/foreignmemory/minios.c
b/tools/libs/foreignmemory/minios.c
index a542e3d..5fcb861 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -51,6 +51,12 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle
*fmem,
return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
}
+int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+ void *addr, unsigned int num)
+{
+ return munmap(addr, num << PAGE_SHIFT);
+}
+
/*
* Local variables:
* mode: C
diff --git a/tools/libs/foreignmemory/netbsd.c
b/tools/libs/foreignmemory/netbsd.c
index 704a096..740c26f 100644
--- a/tools/libs/foreignmemory/netbsd.c
+++ b/tools/libs/foreignmemory/netbsd.c
@@ -94,6 +94,12 @@ void *osdep_map_foreign_batch(xenforeignmem_handle *fmem,
uint32_t dom,
}
[Xen-devel] [PATCH XEN v7 15/29] tools/libs/foreignmemory: use size_t for size arguments.
Surprisingly it appears no callers need updating.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
Acked-by: Ian Jackson
---
v4: New patch
---
tools/libs/foreignmemory/compat.c | 2 +-
tools/libs/foreignmemory/freebsd.c | 4 ++--
.../libs/foreignmemory/include/xenforeignmemory.h | 5 +++--
tools/libs/foreignmemory/linux.c | 23 +++---
tools/libs/foreignmemory/minios.c | 4 ++--
tools/libs/foreignmemory/netbsd.c | 2 +-
tools/libs/foreignmemory/solaris.c | 2 +-
7 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/tools/libs/foreignmemory/compat.c
b/tools/libs/foreignmemory/compat.c
index b8c6fc6..039297c 100644
--- a/tools/libs/foreignmemory/compat.c
+++ b/tools/libs/foreignmemory/compat.c
@@ -23,7 +23,7 @@
void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int
num)
+ const xen_pfn_t *arr, int *err, size_t num)
{
xen_pfn_t *pfn;
unsigned int i;
diff --git a/tools/libs/foreignmemory/freebsd.c
b/tools/libs/foreignmemory/freebsd.c
index 3c3ad09..ed26ebb 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -85,7 +85,7 @@ int osdep_xenforeignmemory_close(xenforeignmemory_handle
*fmem)
void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
const xen_pfn_t *arr, int *err,
- unsigned int num)
+ size_t num)
{
int fd = fmem->fd;
privcmd_mmapbatch_t ioctlx;
@@ -119,7 +119,7 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle
*fmem,
}
int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
- void *addr, unsigned int num)
+ void *addr, size_t num)
{
return munmap(addr, num << PAGE_SHIFT);
}
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index b1cae30..87f72fd 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -56,14 +56,15 @@ int xenforeignmemory_close(xenforeignmemory_handle *xmem);
*/
void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
- unsigned int num);
+ size_t pages);
+
/*
* Unmap a mapping previous created with xenforeignmemory_map().
*
* Returns 0 on success on failure sets errno and returns -1.
*/
int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
- void *addr, unsigned int num);
+ void *addr, size_t pages);
#endif
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 40ecd41..6620391 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -115,10 +115,11 @@ static int map_foreign_batch_single(int fd, uint32_t dom,
* This will keep the request ring full and avoids delays.
*/
static int retry_paged(int fd, uint32_t dom, void *addr,
- const xen_pfn_t *arr, int *err, unsigned int num)
+ const xen_pfn_t *arr, int *err, size_t num)
{
privcmd_mmapbatch_v2_t ioctlx;
-int rc, paged = 0, i = 0;
+int rc, paged = 0;
+size_t i = 0;
do
{
@@ -134,7 +135,7 @@ static int retry_paged(int fd, uint32_t dom, void *addr,
/* At least one gfn is still in paging state */
ioctlx.num = 1;
ioctlx.dom = dom;
-ioctlx.addr = (unsigned long)addr + ((unsigned long)i
[Xen-devel] [PATCH XEN v7 12/29] tools: Implement xc_map_foreign_range(s) in terms of common helper
Both Linux and FreeBSD already implemented these functions using
identical helpers based on xc_map_foreign_pages. Make one copy of
these common helpers and switch all OSes to use them, even those which
previously had a specific lower level implementation of this
functionality.
This is makes two fewer low level interfaces to think about.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libxc/xc_foreign_memory.c | 50 +
tools/libxc/xc_freebsd_osdep.c | 50 -
tools/libxc/xc_linux_osdep.c| 49 -
tools/libxc/xc_minios.c | 43 -
tools/libxc/xc_netbsd.c | 70 -
tools/libxc/xc_solaris.c| 67 ---
6 files changed, 50 insertions(+), 279 deletions(-)
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 2413e75..d1130e6 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -50,6 +50,56 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom,
int prot,
return res;
}
+void *xc_map_foreign_range(xc_interface *xch,
+ uint32_t dom, int size, int prot,
+ unsigned long mfn)
+{
+xen_pfn_t *arr;
+int num;
+int i;
+void *ret;
+
+num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
+arr = calloc(num, sizeof(xen_pfn_t));
+if ( arr == NULL )
+return NULL;
+
+for ( i = 0; i < num; i++ )
+arr[i] = mfn + i;
+
+ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+free(arr);
+return ret;
+}
+
+void *xc_map_foreign_ranges(xc_interface *xch,
+uint32_t dom, size_t size,
+int prot, size_t chunksize,
+privcmd_mmap_entry_t entries[],
+int nentries)
+{
+xen_pfn_t *arr;
+int num_per_entry;
+int num;
+int i;
+int j;
+void *ret;
+
+num_per_entry = chunksize >> XC_PAGE_SHIFT;
+num = num_per_entry * nentries;
+arr = calloc(num, sizeof(xen_pfn_t));
+if ( arr == NULL )
+return NULL;
+
+for ( i = 0; i < nentries; i++ )
+for ( j = 0; j < num_per_entry; j++ )
+arr[i * num_per_entry + j] = entries[i].mfn + j;
+
+ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+free(arr);
+return ret;
+}
+
/*
* stub for all not yet converted OSes (NetBSD and Solaris). New OSes should
* just implement xc_map_foreign_bulk.
diff --git a/tools/libxc/xc_freebsd_osdep.c b/tools/libxc/xc_freebsd_osdep.c
index 6b440ee..7745d28 100644
--- a/tools/libxc/xc_freebsd_osdep.c
+++ b/tools/libxc/xc_freebsd_osdep.c
@@ -125,56 +125,6 @@ void *xc_map_foreign_bulk(xc_interface *xch,
return addr;
}
-void *xc_map_foreign_range(xc_interface *xch,
- uint32_t dom, int size, int prot,
- unsigned long mfn)
-{
-xen_pfn_t *arr;
-int num;
-int i;
-void *ret;
-
-num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
-free(arr);
-return ret;
-}
-
-void *xc_map_foreign_ranges(xc_interface *xch,
-uint32_t dom, size_t size,
-int prot, size_t chunksize,
-privcmd_mmap_entry_t entries[],
-int nentries)
-{
-xen_pfn_t *arr;
-int num_per_entry;
-int num;
-int i;
-int j;
-void *ret;
-
-num_per_entry = chunksize >> XC_PAGE_SHIFT;
-num = num_per_entry * nentries;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < nentries; i++ )
-for ( j = 0; j < num_per_entry; j++ )
-arr[i * num_per_entry + j] = entries[i].mfn + j;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
-free(arr);
-return ret;
-}
-
/*
* Local variables:
* mode: C
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 39c88ce..acf44ce 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -290,55 +290,6 @@ void *xc_map_foreign_bulk(xc_interface *xch,
return addr;
}
-void *xc_map_foreign_range(xc_interface *xch,
- uint32_t dom, int size, int prot,
- unsigned long mfn)
-{
-xen_pfn_t *arr;
-int num;
-int i;
-void *ret;
-
-num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
-
[Xen-devel] [PATCH XEN v7 10/29] tools/libxc: drop xc_map_foreign_bulk_compat wrappers
On Solaris and NetBSD xc_map_foreign_bulk is implemented by calling
xc_map_foreign_bulk_compat and xc_map_foreign_bulk_compat is exposed
as a symbol by libxenctrl.so.
Remove these wrappers and turn the compat function into the real thing
surrounded by the appropriate ifdef.
As this is a compat function all new ports should instead implement
xc_map_foreign_bulk properly, hence the ifdef should never be
expanded.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libxc/xc_foreign_memory.c | 13 +
tools/libxc/xc_netbsd.c | 7 ---
tools/libxc/xc_private.h| 5 -
tools/libxc/xc_solaris.c| 7 ---
4 files changed, 9 insertions(+), 23 deletions(-)
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 9c705b6..b205bca 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -50,10 +50,14 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom,
int prot,
return res;
}
-/* stub for all not yet converted OSes */
-void *xc_map_foreign_bulk_compat(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int
num)
+/*
+ * stub for all not yet converted OSes (NetBSD and Solaris). New OSes should
+ * just implement xc_map_foreign_bulk.
+ */
+#if defined(__NetBSD__) || defined(__sun__)
+void *xc_map_foreign_bulk(xc_interface *xch,
+ uint32_t dom, int prot,
+ const xen_pfn_t *arr, int *err, unsigned int num)
{
xen_pfn_t *pfn;
unsigned int i;
@@ -90,6 +94,7 @@ void *xc_map_foreign_bulk_compat(xc_interface *xch,
return ret;
}
+#endif
/*
* Local variables:
diff --git a/tools/libxc/xc_netbsd.c b/tools/libxc/xc_netbsd.c
index 5e3b343..d7f7f31 100644
--- a/tools/libxc/xc_netbsd.c
+++ b/tools/libxc/xc_netbsd.c
@@ -67,13 +67,6 @@ int osdep_privcmd_close(xc_interface *xch)
return close(fd);
}
-void *xc_map_foreign_bulk(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int num)
-{
-return xc_map_foreign_bulk_compat(xch, dom, prot, arr, err, num);
-}
-
void *xc_map_foreign_batch(xc_interface *xch,
uint32_t dom, int prot,
xen_pfn_t *arr, int num)
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index c93df7f..ecf2451 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -107,11 +107,6 @@ int osdep_privcmd_close(xc_interface *xch);
void *osdep_alloc_hypercall_buffer(xc_interface *xch, int npages);
void osdep_free_hypercall_buffer(xc_interface *xch, void *ptr, int npages);
-/* Stub for not yet converted OSes */
-void *xc_map_foreign_bulk_compat(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int
num);
-
void xc_report_error(xc_interface *xch, int code, const char *fmt, ...)
__attribute__((format(printf,3,4)));
void xc_reportv(xc_interface *xch, xentoollog_logger *lg, xentoollog_level,
diff --git a/tools/libxc/xc_solaris.c b/tools/libxc/xc_solaris.c
index 18622fa..5e72dee 100644
--- a/tools/libxc/xc_solaris.c
+++ b/tools/libxc/xc_solaris.c
@@ -94,13 +94,6 @@ void *xc_map_foreign_batch(xc_interface *xch,
}
-void *xc_map_foreign_bulk(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int num)
-{
-return xc_map_foreign_bulk_compat(xch, dom, prot, arr, err, num);
-}
-
void *xc_map_foreign_range(xc_interface *xch,
uint32_t dom,
int size, int prot,
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 02/29] tools: Refactor "xentoollog" into its own library
In attempting to disaggregate libxenctrl I found that many of the
pieces were going to want access to this library, so split it out (as
it probably should always have been).
Various build adjustments are needed. In particular things which use
xtl_* themselves now need to explicity link against the library.
This has a nice side effect which is that users of libxl no longer
need to link against libxenctrl just to create a logger, which was
counter to the principal that applications using libxl shouldn't be
required to look behind the curtain. This means that xl no longer
links against libxenctrl.
The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
Acked-by: Wei Liu
---
Must be applied with:
- "qemu-xen-traditional: Use xentoollog as a separate library" and a
corresponding QEMU_TAG update folded here.
- "mini-os: Include libxentoollog with libxc" and a corresponding bump
to MINIOS_UPSTREAM_REVISION folded in here.
Note that this patch was applied as c7d3afbb44b4 but reverted via
ec0712576198. See
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01153.html
As of v7 the QEMU_TAG and MINIOS_UPSTREAM_REVISION updates
corresponding to that push are included in the patch (since the master
branches of those repos has not been reverted). If those patches are
subsequently reverted as described in the mail then git am will gripe
about this commit.
v2: Update doc at same time
v3: Move into tools/libs/toollog.
v6: Dropped spurious debugging changes to tools/ocaml/Makefile.rules
v7: Added Config.mk update
Added mk-headers-$(XEN_TARGET_ARCH) build dependency instead of
open coding the recursion.
---
.gitignore | 1 +
Config.mk | 12 ++---
stubdom/Makefile | 22 +++-
stubdom/grub/Makefile | 1 +
tools/Makefile | 3 ++
tools/Rules.mk | 14 +++--
tools/libs/Makefile| 7 +++
tools/libs/toollog/Makefile| 59 ++
tools/{libxc => libs/toollog}/include/xentoollog.h | 0
tools/libs/toollog/libxentoollog.map | 12 +
tools/{libxc => libs/toollog}/xtl_core.c | 0
tools/{libxc => libs/toollog}/xtl_logger_stdio.c | 0
tools/libxc/Makefile | 7 ++-
tools/libxl/Makefile | 15 +++---
tools/ocaml/libs/xentoollog/Makefile | 6 +--
tools/ocaml/libs/xentoollog/genlevels.py | 2 +-
tools/python/setup.py | 5 +-
tools/xenpaging/Makefile | 2 +-
18 files changed, 139 insertions(+), 29 deletions(-)
create mode 100644 tools/libs/Makefile
create mode 100644 tools/libs/toollog/Makefile
rename tools/{libxc => libs/toollog}/include/xentoollog.h (100%)
create mode 100644 tools/libs/toollog/libxentoollog.map
rename tools/{libxc => libs/toollog}/xtl_core.c (100%)
rename tools/{libxc => libs/toollog}/xtl_logger_stdio.c (100%)
diff --git a/.gitignore b/.gitignore
index 91e1430..a2c85e1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -58,6 +58,7 @@ stubdom/gcc-*
stubdom/include
stubdom/ioemu
stubdom/xenstore
+stubdom/libxentoollog-*
stubdom/libxc-*
stubdom/lwip-*
stubdom/mini-os-*
diff --git a/Config.mk b/Config.mk
index 216a642..8fc7767 100644
--- a/Config.mk
+++ b/Config.mk
@@ -255,9 +255,9 @@ MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
endif
OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
QEMU_UPSTREAM_REVISION ?= master
-MINIOS_UPSTREAM_REVISION ?= bccd90071e863ec22216a000f1a07035e2f226ff
-# Mon Nov 23 16:34:31 2015 +
-# Add a .gitignore
+MINIOS_UPSTREAM_REVISION ?= d25773c8afa2f4dbbb466116daeb60159ddd22bd
+# Thu Dec 3 11:23:25 2015 +
+# mini-os: Include libxentoollog with libxc
SEABIOS_UPSTREAM_REVISION ?= rel-1.9.0
# Tue Nov 17 09:18:44 2015 -0500
@@ -266,9 +266,9 @@ SEABIOS_UPSTREAM_REVISION ?= rel-1.9.0
ETHERBOOT_NICS ?= rtl8139 8086100e
-QEMU_TRADITIONAL_REVISION ?= 91c15bfaec1764ce2896a393eabee1183afe1130
-# Wed Dec 9 11:47:35 2015 +
-# net: pcnet: add check to validate receive data size(CVE-2015-7504)
+QEMU_TRADITIONAL_REVISION ?= 9fad9ed285835caef64bb8dab352e287ad8538c2
+# Thu Dec 3 11:23:16 2015 +
+# qemu-xen-traditional: Use xentoollog as a separate library
# Specify which qemu-dm to use. This may be `ioemu' to use the old
# Mercurial in-tree version, or a local directory, or a git URL.
diff --git a/stubdom/Makefile b/stubdom/Makefile
index fd84024..9c77205 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -314,6 +314,11 @@ mk-headers-$(XEN_TARGET_ARCH): $(IOEMU_LINKFARM_TARGET)
ln -sf $(wildcard $(XEN_RO
[Xen-devel] [PATCH XEN v7 07/29] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.
libxengnttab will provide a stable API and ABI for accessing the
grant table devices.
The functions are moved into the xengnt{tab,shr} namespace to make a
clean break from libxc and avoid ambiguity regarding which interfaces
are stable.
All in-tree users are updated to use the new names.
Upon request (via #define XC_WANT_COMPAT_GNTTAB_API) libxenctrl will
provide a compat API for the old names. This is used by qemu-xen for
the time being. qemu-xen-traditional is updated in lockstep.
This leaves a few grant table related functions which go via privcmd
(EVTCHNOP) rather than ioctls on the /dev/xen/gnt* devices in
libxenctrl. Specifically:
- xc_gnttab_get_version
- xc_gnttab_map_table_v1
- xc_gnttab_map_table_v2
- xc_gnttab_op
These functions do not appear to be needed by qemu-dm, qemu-pv
(provision of device model to HVM guests and PV backends respectively)
or by libvchan suggesting they are not needed by non-toolstack uses of
event channels.
The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.
After this change libxenvchan no longer needs to link against
libxenctrl. It still needs xenctrl.h in one file for xen_mb and
friends.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
Must be applied with:
- "qemu-xen-traditional: Use libxengnttab" and a corresponding
QEMU_TAG update folded here.
- "mini-os: Include libxengnttab with libxc"" and a corresponding
bump to MINIOS_UPSTREAM_REVISION folded in here.
v3:
- Remove SHLIB_libxenctrl from SHDEPS_libxenvchan, and replace with
SHLIB_libxentoollog.
- Move to tools/libs/gnttab
- Adjust for rebase over 31cf2ca75181 "tools/libxc: linux: Don't use
getpagesize() when unmapping the grants"
v5: Allow _close(NULL).
v6: The extensive API document updates from the previous round of
review have been implemented in "tools/libs/gnttab: Extensive
updates to API documentation." later in the series, so as not to
add further functional changes than already required to this
refactoring patch.
v7: Added mk-headers-$(XEN_TARGET_ARCH) build dependency instead of
open coding the recursion.
s/gnttab_munmap/gnttab_unmap/ and s/gntshr_munmap/gntshr_unshare/
in the API and equivalents in the internals/osdeps etc.
---
.gitignore | 2 +
stubdom/Makefile | 17 +-
tools/Makefile | 3 +
tools/Rules.mk | 14 +-
tools/console/Makefile | 5 +-
tools/console/daemon/io.c | 21 +-
tools/libs/Makefile| 1 +
tools/libs/evtchn/minios.c | 5 +-
tools/libs/gnttab/Makefile | 69 +
tools/libs/gnttab/gntshr_core.c| 95 ++
.../xc_nognttab.c => libs/gnttab/gntshr_unimp.c} | 34 ++-
tools/libs/gnttab/gnttab_core.c| 124
tools/libs/gnttab/gnttab_unimp.c | 89 ++
tools/libs/gnttab/include/xengnttab.h | 216 ++
tools/libs/gnttab/libxengnttab.map | 23 ++
tools/libs/gnttab/linux.c | 329 +
tools/libs/gnttab/minios.c | 117
tools/libs/gnttab/private.h| 47 +++
tools/libvchan/Makefile| 8 +-
tools/libvchan/init.c | 26 +-
tools/libvchan/io.c| 8 +-
tools/libvchan/libxenvchan.h | 6 +-
tools/libxc/Makefile | 15 +-
tools/libxc/include/xenctrl.h | 168 ---
tools/libxc/include/xenctrl_compat.h | 48 +++
tools/libxc/xc_gnttab.c| 53
tools/libxc/xc_gnttab_compat.c | 111 +++
tools/libxc/xc_linux_osdep.c | 280 --
tools/libxc/xc_minios.c| 73 -
tools/libxc/xc_nogntshr.c | 46 ---
tools/libxc/xc_private.c | 80 -
tools/libxc/xc_private.h | 24 --
tools/xenstore/Makefile| 4 +-
tools/xenstore/xenstored_core.h| 4 +-
tools/xenstore/xenstored_domain.c | 24 +-
tools/xenstore/xenstored_minios.c | 5 +-
36 files changed, 1393 insertions(+), 801 deletions(-)
create mode 100644 tools/libs/gnttab/Makefile
create mode 100644 tools/libs/gnttab/gntshr_core.c
rename tools/{libxc/xc_nognttab.c => libs/gnttab/gntshr_unimp.c} (52%)
create mode 100644 tools/libs/gnttab/gnttab_core.c
create mode 100644 tools/libs/gnttab/gnttab_unimp.c
create mode 100644 tools/libs
[Xen-devel] [PATCH XEN v7 09/29] tools: Refactor hypercall calling wrappers into libxencall.
libxencall will provide a stable API and ABI for calling hypercalls (although those hypercalls themselves may not have a stable API). As well as the hypercall buffer infrastructure needed in order to safely provide pointer arguments to hypercalls. libxenctrl encapsulates a instance of this interface, so users of that library are not currently subjected to any actual changes. However all hypercalls made internally by libxc now use the correct interface. It is expected that most users of this library will be other libraries providing a higher level interface, rather than applications directly. Only the basic functionality to allocate hypercall safe memory is moved, the type safe stuff and bounce buffers remain in libxc. Note that the functionality to map foreign pages using privcmd is not yet moved, meaning that an xc_interface will now contain two open privcmd file descriptors. Foreign memory mapping is logically separate functionality and will be moved into its own library. The new library uses a version script to ensure that only expected symbols are exported and to version them such that ABI guarantees can be kept in the future. Signed-off-by: Ian Campbell Acked-by: Wei Liu --- Must be applied with: - "qemu-xen-traditional: Add libxencall to rpath-link" and a corresponding QEMU_TAG update folded here. - "mini-os: Include libxencall with libxc" and a corresponding bump to MINIOS_UPSTREAM_REVISION folded in here. v3: Moved to tools/libs/call Ported new wrappers (altp2m) v5: Allow _close(NULL). v6: Use size_t for nr_pages throughout. Rebase over "libxc: prefer using privcmd character device" v7: Added mk-headers-$(XEN_TARGET_ARCH) build dependency instead of open coding the recursion. Remove incorrect/spurious APP_LDLIBS (which anyway was removed by a later patch) --- .gitignore| 2 + stubdom/Makefile | 17 +++- tools/Makefile| 1 + tools/Rules.mk| 7 +- tools/libs/Makefile | 1 + tools/libs/call/Makefile | 67 + tools/libs/call/buffer.c | 192 ++ tools/libs/call/core.c| 147 + tools/libs/call/freebsd.c | 140 +++ tools/libs/call/include/xencall.h | 84 + tools/libs/call/libxencall.map| 19 tools/libs/call/linux.c | 138 +++ tools/libs/call/minios.c | 81 tools/libs/call/netbsd.c | 121 tools/libs/call/private.h | 68 ++ tools/libs/call/solaris.c | 97 +++ tools/libxc/Makefile | 7 +- tools/libxc/xc_altp2m.c | 64 - tools/libxc/xc_domain.c | 105 +++-- tools/libxc/xc_evtchn.c | 9 +- tools/libxc/xc_flask.c| 8 +- tools/libxc/xc_freebsd_osdep.c| 47 -- tools/libxc/xc_gnttab.c | 9 +- tools/libxc/xc_hcall_buf.c| 138 ++- tools/libxc/xc_kexec.c| 36 +++ tools/libxc/xc_linux_osdep.c | 49 -- tools/libxc/xc_minios.c | 32 --- tools/libxc/xc_misc.c | 79 ++-- tools/libxc/xc_netbsd.c | 40 tools/libxc/xc_private.c | 64 + tools/libxc/xc_private.h | 76 +-- tools/libxc/xc_solaris.c | 16 tools/libxc/xc_tmem.c | 7 +- tools/misc/Makefile | 4 +- tools/xcutils/Makefile| 2 +- tools/xenpaging/Makefile | 2 +- 36 files changed, 1344 insertions(+), 632 deletions(-) create mode 100644 tools/libs/call/Makefile create mode 100644 tools/libs/call/buffer.c create mode 100644 tools/libs/call/core.c create mode 100644 tools/libs/call/freebsd.c create mode 100644 tools/libs/call/include/xencall.h create mode 100644 tools/libs/call/libxencall.map create mode 100644 tools/libs/call/linux.c create mode 100644 tools/libs/call/minios.c create mode 100644 tools/libs/call/netbsd.c create mode 100644 tools/libs/call/private.h create mode 100644 tools/libs/call/solaris.c diff --git a/.gitignore b/.gitignore index 9241c54..2899852 100644 --- a/.gitignore +++ b/.gitignore @@ -61,6 +61,7 @@ stubdom/xenstore stubdom/libxentoollog-* stubdom/libxenevtchn-* stubdom/libxengnttab-* +stubdom/libxencall-* stubdom/libxc-* stubdom/lwip-* stubdom/mini-os-* @@ -90,6 +91,7 @@ config/Docs.mk tools/libs/toollog/headers.chk tools/libs/evtchn/headers.chk tools/libs/gnttab/headers.chk +tools/libs/call/headers.chk tools/blktap2/daemon/blktapctrl tools/blktap2/drivers/img2qcow tools/blktap2/drivers/lock-util diff --git a/stubdom/Makefile b/stubdom/Makefile index 2dbf4a8..5bf4ed6 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -331,6 +3
[Xen-devel] [PATCH QEMU-XEN v7 0/8] Begin to disentangle libxenctrl and provide some stable libraries
We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.
This is the qemu-xen part of the first phase of that change.
This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.
Ian Campbell (8):
xen_console: correctly cleanup primary console on teardown.
xen: Switch to libxenevtchn interface for compat shims.
xen: Switch to libxengnttab interface for compat shims.
xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
xen: Switch uses of xc_map_foreign_{pages,bulk} to use
libxenforeignmemory API.
xen: Use stable library interfaces when they are available.
xen: domainbuild: reopen libxenctrl interface after forking for domain
watcher.
xen: make it possible to build without the Xen PV domain builder
configure| 57 -
hw/block/xen_disk.c | 38 +--
hw/char/xen_console.c| 19 +++---
hw/display/xenfb.c | 28 +
hw/net/xen_nic.c | 18 +++---
hw/xen/xen_backend.c | 44 ++---
hw/xenpv/Makefile.objs | 4 +-
hw/xenpv/xen_domainbuild.c | 9 ++-
hw/xenpv/xen_machine_pv.c| 15 +++--
include/hw/xen/xen_backend.h | 5 +-
include/hw/xen/xen_common.h | 147 ++-
xen-common.c | 6 ++
xen-hvm.c| 39 ++--
xen-mapcache.c | 6 +-
14 files changed, 299 insertions(+), 136 deletions(-)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH QEMU-XEN v7 7/8] xen: domainbuild: reopen libxenctrl interface after forking for domain watcher.
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.
Reopen the handle after fork and therefore do away with xc_fd().
Signed-off-by: Ian Campbell
Acked-by: Stefano Stabellini
---
The fact that xc_fd hasn't been useful since at least Xen 4.1 makes me
question the utility of this domainbuild in QEMU. Perhaps we should
just nuke it?
---
hw/xenpv/xen_domainbuild.c | 9 ++---
include/hw/xen/xen_common.h | 17 -
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
index ac0e5ac..f9be029 100644
--- a/hw/xenpv/xen_domainbuild.c
+++ b/hw/xenpv/xen_domainbuild.c
@@ -174,12 +174,15 @@ static int xen_domain_watcher(void)
for (i = 3; i < n; i++) {
if (i == fd[0])
continue;
-if (i == xc_fd(xen_xc)) {
-continue;
-}
close(i);
}
+/*
+ * Reopen xc interface, since the original is unsafe after fork
+ * and was closed above.
+ */
+xen_xc = xc_interface_open(0, 0, 0);
+
/* ignore term signals */
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 310d6ef..8c4fc42 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -118,12 +118,6 @@ static inline XenXC xen_xc_interface_open(void *logger,
void *dombuild_logger,
/* See below for xenforeignmemory_map */
#define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
-static inline int xc_fd(int xen_xc)
-{
-return xen_xc;
-}
-
-
static inline int xc_domain_populate_physmap_exact
(XenXC xc_handle, uint32_t domid, unsigned long nr_extents,
unsigned int extent_order, unsigned int mem_flags, xen_pfn_t
*extent_start)
@@ -197,11 +191,6 @@ static inline XenXC xen_xc_interface_open(void *logger,
void *dombuild_logger,
/* See below for xenforeignmemory_map */
#define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
-/* FIXME There is no way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470 */
typedef xc_interface *XenXC;
@@ -218,12 +207,6 @@ static inline XenXC xen_xc_interface_open(void *logger,
void *dombuild_logger,
{
return xc_interface_open(logger, dombuild_logger, open_flags);
}
-
-/* FIXME There is now way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
#endif
/* Xen before 4.2 */
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 25/29] tools/libs/call: linux: touch newly allocated pages after madvise lockdown
This avoids a potential issue with a fork after allocation but before
madvise.
Signed-off-by: Ian Campbell
---
v7: New, replacing "tools/libs/call: linux: avoid forking between mmap
and madvise".
---
tools/libs/call/linux.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index 3641e41..651f380 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -88,7 +88,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t npages)
{
size_t size = npages * PAGE_SIZE;
void *p;
-int rc, saved_errno;
+int rc, i, saved_errno;
/* Address returned by mmap is page aligned. */
p = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
@@ -107,6 +107,18 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t
npages)
goto out;
}
+/*
+ * Touch each page in turn to force them to be un-CoWed, in case a
+ * fork happened in another thread at an inopportune moment
+ * above. The madvise() will prevent any subsequent fork calls from
+ * causing the same problem.
+ */
+for ( i = 0; i < npages ; i++ )
+{
+char *c = (char *)p + (i*PAGE_SIZE);
+*c = 0;
+}
+
return p;
out:
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v7 0/4] Begin to disentangle libxenctrl and provide some stable libraries
We intend to stabilise some parts of the libxenctrl interface by splitting out some functionality into separate stable libraries. This is the qemu-xen-traditional part of the first phase of that change. This mail is (or is intended to be) a reply to a "0/" super-intro mail covering all of the related patch series and which contains more details. Ian Campbell (4): qemu-xen-traditional: Use libxenevtchn qemu-xen-traditional: Use libxengnttab qemu-xen-traditional: Add libxencall to rpath-link qemu-xen-traditional: Add libxenforeignmemory to rpath-link hw/xen_backend.c | 30 +++--- hw/xen_backend.h | 4 ++-- hw/xen_common.h | 2 ++ hw/xen_console.c | 4 ++-- hw/xen_disk.c | 24 i386-dm/helper2.c | 19 ++- xen-hooks.mak | 7 +++ 7 files changed, 50 insertions(+), 40 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH QEMU-XEN v7 3/8] xen: Switch to libxengnttab interface for compat shims.
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
One such library will be libxengnttab which provides access to grant
tables.
In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the gnttab shim will disappear
for versions of Xen which include libxengnttab.
To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.
Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
Rebase onto "xen_console: correctly cleanup primary console on
teardown."
v5: Rebase over b4f72e31b924 "hw/net/xen_nic.c: Free 'netdev->txs'
when map 'netdev->rxs' fails" which added a new gnttab_munmap.
v7: s/gnttab_munmap/gnttab_unmap/ to reflect change in the library.
---
hw/block/xen_disk.c | 38 --
hw/char/xen_console.c| 4 ++--
hw/net/xen_nic.c | 18 +-
hw/xen/xen_backend.c | 10 +-
include/hw/xen/xen_backend.h | 2 +-
include/hw/xen/xen_common.h | 42 --
6 files changed, 69 insertions(+), 45 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 8146650..e1f8dd4 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -171,11 +171,11 @@ static gint int_cmp(gconstpointer a, gconstpointer b,
gpointer user_data)
static void destroy_grant(gpointer pgnt)
{
PersistentGrant *grant = pgnt;
-XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
-if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
+if (xengnttab_unmap(gnt, grant->page, 1) != 0) {
xen_be_printf(&grant->blkdev->xendev, 0,
- "xc_gnttab_munmap failed: %s\n",
+ "xengnttab_unmap failed: %s\n",
strerror(errno));
}
grant->blkdev->persistent_gnt_count--;
@@ -188,11 +188,11 @@ static void remove_persistent_region(gpointer data,
gpointer dev)
{
PersistentRegion *region = data;
struct XenBlkDev *blkdev = dev;
-XenGnttab gnt = blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
-if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
+if (xengnttab_unmap(gnt, region->addr, region->num) != 0) {
xen_be_printf(&blkdev->xendev, 0,
- "xc_gnttab_munmap region %p failed: %s\n",
+ "xengnttab_unmap region %p failed: %s\n",
region->addr, strerror(errno));
}
xen_be_printf(&blkdev->xendev, 3,
@@ -327,7 +327,7 @@ err:
static void ioreq_unmap(struct ioreq *ioreq)
{
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
int i;
if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
@@ -337,8 +337,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
if (!ioreq->pages) {
return;
}
-if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_be_printf(&ioreq->blkdev->xendev, 0, "xc_gnttab_munmap failed:
%s\n",
+if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
+xen_be_printf(&ioreq->blkdev->xendev, 0,
+ "xengnttab_unmap failed: %s\n",
strerror(errno));
}
ioreq->blkdev->cnt_map -= ioreq->num_unmap;
@@ -348,8 +349,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
if (!ioreq->page[i]) {
continue;
}
-if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
-xen_be_printf(&ioreq->blkdev->xendev, 0, "xc_gnttab_munmap
failed: %s\n",
+if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) {
+xen_be_printf(&ioreq->blkdev->xendev, 0,
+ "xengnttab_unmap failed: %s\n",
strerror(errno));
}
ioreq->blkdev->cnt_map--;
@@ -361,7 +363,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
static int ioreq_map(struct ioreq *ioreq)
{
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -412,7 +414,7 @@ static int
[Xen-devel] [PATCH QEMU-XEN v7 6/8] xen: Use stable library interfaces when they are available.
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
Previous patches have already laid the groundwork for using these by
switching the existing compatibility shims to reflect the intefaces to
these libraries.
So all which remains is to update configure to detect the libraries
and enable their use. Although they are notionally independent we take
an all or nothing approach to the three libraries since they were
added at the same time.
The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.
Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
4.7 which adds these libraries.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
---
v6: Two minor formatting things.
Rebase onto "xen: fix usage of xc_domain_create in domain
builder", required adjusting the configure script changes.
The rebase wasn't entirely trivial (semantically), so dropped
Stefano's reviwed by.
v5: Remove ifdef check when undeffing the compat stuff.
s/now way/no way/
v4: xenforeignmemory_open is now a compat wrapper, so no ifdef.
Simplify configury by asserting that interface version 470 will
always have the libraries (lack of them makes it 460).
Ran checkpatch and fixed everything except:
ERROR: need consistent spacing around '*' (ctx:WxV)
+typedef xc_interface *XenXC;
Which I think is a false +ve.
Simpler configure stuff
---
configure | 42 +-
include/hw/xen/xen_common.h | 35 +--
2 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index b9552fd..162aa16 100755
--- a/configure
+++ b/configure
@@ -1938,6 +1938,7 @@ fi
if test "$xen" != "no" ; then
xen_libs="-lxenstore -lxenctrl -lxenguest"
+ xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
# First we test whether Xen headers and libraries are available.
# If no, we are done and there is no Xen support.
@@ -1960,16 +1961,52 @@ EOF
# Xen unstable
elif
cat > $TMPC <
+#include
+#include
+#include
+#include
#include
+#include
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
int main(void) {
xc_interface *xc = NULL;
+ xenforeignmemory_handle *xfmem;
+ xenevtchn_handle *xe;
+ xengnttab_handle *xg;
xen_domain_handle_t handle;
+
+ xs_daemon_open();
+
+ xc = xc_interface_open(0, 0, 0);
+ xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+ xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+ xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+ xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
xc_domain_create(xc, 0, handle, 0, NULL, NULL);
+
+ xfmem = xenforeignmemory_open(0, 0);
+ xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+ xe = xenevtchn_open(0, 0);
+ xenevtchn_fd(xe);
+
+ xg = xengnttab_open(0, 0);
+ xengnttab_map_grant_ref(xg, 0, 0, 0);
+
return 0;
}
EOF
- compile_prog "" "$xen_libs"
+ compile_prog "" "$xen_libs $xen_stable_libs"
then
xen_ctrl_version=470
xen=yes
@@ -2153,6 +2190,9 @@ EOF
fi
if test "$xen" = yes; then
+if test $xen_ctrl_version -ge 470 ; then
+ libs_softmmu="$xen_stable_libs $libs_softmmu"
+fi
libs_softmmu="$xen_libs $libs_softmmu"
fi
fi
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 55809b4..310d6ef 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -6,6 +6,15 @@
#include
#include
+/*
+ * If we have new enough libxenctrl then we do not want/need these compat
+ * interfaces, despite what the user supplied cflags might say. They
+ * must be undefined before including xenctrl.h
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+
#include
#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
# include
@@ -150,8 +159,8 @@ static inline void xs_close(struct xs_handle *xsh)
}
-/* Xen 4.1 */
-#else
+/* Xen 4.1 thru 4.6 */
+#elif CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
typedef xc_interface *XenXC;
typedef xc_interface *xenforeignmemory_handle;
@@ -188,6 +197,28 @@ static inline XenXC xen_xc_interface_open(void *logger,
void *dombuild_logger,
/* See below for xenforeignmemory_map */
#define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
+/* FIXME There is no way to have the xen fd */
+static inline int xc_fd(xc_interface *xen_xc)
+{
+return -1;
+}
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470 */
+
+typedef xc_interface *XenXC;
+
+# define XC_INTERFACE_FMT "%p"
+# define XC_HANDLER_INITIAL_VALUENULL
+
+#include
+#include
+#include
+
+static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
+
[Xen-devel] [PATCH XEN v7 26/29] tools/libs/{call, evtchn}: Document requirements around forking.
Much like for gnttab and foreignmemory xencall hypercall buffers need care. Evtchn is a bit simpler (no magic mappings) but may not work from parent + child simultaneously, document "parent only" since it is consistent with the others. Signed-off-by: Ian Campbell --- v7: New --- tools/libs/call/include/xencall.h | 28 tools/libs/evtchn/include/xenevtchn.h | 23 +++ 2 files changed, 47 insertions(+), 4 deletions(-) diff --git a/tools/libs/call/include/xencall.h b/tools/libs/call/include/xencall.h index 3f325f0..559624a 100644 --- a/tools/libs/call/include/xencall.h +++ b/tools/libs/call/include/xencall.h @@ -36,11 +36,39 @@ typedef struct xencall_handle xencall_handle; /* * Return a handle onto the hypercall driver. Logs errors. + * * + * Note: After fork(2) a child process must not use any opened + * xencall handle inherited from their parent, nor access any + * hypercall argument buffers associated with that handle. + * + * The child must open a new handle if they want to interact with + * xencall. + * + * Calling exec(2) in a child will safely (and reliably) reclaim any + * resources which were allocated via a xencall_handle in the parent. + * + * A child which does not call exec(2) may safely call xencall_close() + * on a xencall_handle inherited from their parent. This will attempt + * to reclaim any resources associated with that handle. Note that in + * some implementations this reclamation may not be completely + * effective, in this case any affected resources remain allocated. + * + * Calling xencall_close() is the only safe operation on a + * xencall_handle which has been inherited. */ xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags); /* * Close a handle previously allocated with xencall_open(). + * + * Under normal circumstances (i.e. not in the child after a fork) any + * allocated hypercall argument buffers should be freed using the + * appropriate xencall_free_*() prior to closing the handle in order + * to free up resources associated with those mappings. + * + * This is the only function which may be safely called on a + * xencall_handle in a child after a fork. xencall_free_*() must not + * be called under such circumstances. */ int xencall_close(xencall_handle *xcall); diff --git a/tools/libs/evtchn/include/xenevtchn.h b/tools/libs/evtchn/include/xenevtchn.h index 60da2a3..bb24462 100644 --- a/tools/libs/evtchn/include/xenevtchn.h +++ b/tools/libs/evtchn/include/xenevtchn.h @@ -45,10 +45,25 @@ typedef struct xentoollog_logger xentoollog_logger; * Return a handle to the event channel driver, or NULL on failure, in * which case errno will be set appropriately. * - * Note: - * After fork a child process must not use any opened evtchn - * handle inherited from their parent. They must open a new handle if - * they want to interact with evtchn. + * Note: After fork(2) a child process must not use any opened evtchn + * handle inherited from their parent, nor access any grant mapped + * areas associated with that handle. + * + * The child must open a new handle if they want to interact with + * evtchn. + * + * Calling exec(2) in a child will safely (and reliably) reclaim any + * allocated resources via a xenevtchn_handle in the parent. + * + * A child which does not call exec(2) may safely call + * xenevtchn_close() on a xenevtchn_handle inherited from their + * parent. This will attempt to reclaim any resources associated with + * that handle. Note that in some implementations this reclamation may + * not be completely effective, in this case any affected resources + * remain allocated. + * + * Calling xenevtchn_close() is the only safe operation on a + * xenevtchn_handle which has been inherited. */ /* Currently no flags are defined */ xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned open_flags); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH QEMU-XEN v7 2/8] xen: Switch to libxenevtchn interface for compat shims.
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
One such library will be libxenevtchn which provides access to event
channels.
In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the evtchn shim will disappear
for versions of Xen which include libxenevtchn.
To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.
Note that this patch does not add any support for actually using
libxenevtchn, it just adjusts the existing shims.
Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
---
hw/xen/xen_backend.c | 31 ---
include/hw/xen/xen_backend.h | 2 +-
include/hw/xen/xen_common.h | 44 ++--
xen-hvm.c| 25 +
4 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 2510e2e..ae2a1f0 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char
*type, int dom, int dev,
xendev->debug = debug;
xendev->local_port = -1;
-xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
-if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+xendev->evtchndev = xenevtchn_open(NULL, 0);
+if (xendev->evtchndev == NULL) {
xen_be_printf(NULL, 0, "can't open evtchn device\n");
g_free(xendev);
return NULL;
}
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
xen_be_printf(NULL, 0, "can't open gnttab device\n");
-xc_evtchn_close(xendev->evtchndev);
+xenevtchn_close(xendev->evtchndev);
g_free(xendev);
return NULL;
}
@@ -306,8 +306,8 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
g_free(xendev->fe);
}
-if (xendev->evtchndev != XC_HANDLER_INITIAL_VALUE) {
-xc_evtchn_close(xendev->evtchndev);
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
}
if (xendev->gnttabdev != XC_HANDLER_INITIAL_VALUE) {
xc_gnttab_close(xendev->gnttabdev);
@@ -691,13 +691,14 @@ static void xen_be_evtchn_event(void *opaque)
struct XenDevice *xendev = opaque;
evtchn_port_t port;
-port = xc_evtchn_pending(xendev->evtchndev);
+port = xenevtchn_pending(xendev->evtchndev);
if (port != xendev->local_port) {
-xen_be_printf(xendev, 0, "xc_evtchn_pending returned %d (expected
%d)\n",
+xen_be_printf(xendev, 0,
+ "xenevtchn_pending returned %d (expected %d)\n",
port, xendev->local_port);
return;
}
-xc_evtchn_unmask(xendev->evtchndev, port);
+xenevtchn_unmask(xendev->evtchndev, port);
if (xendev->ops->event) {
xendev->ops->event(xendev);
@@ -740,14 +741,14 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
if (xendev->local_port != -1) {
return 0;
}
-xendev->local_port = xc_evtchn_bind_interdomain
+xendev->local_port = xenevtchn_bind_interdomain
(xendev->evtchndev, xendev->dom, xendev->remote_port);
if (xendev->local_port == -1) {
-xen_be_printf(xendev, 0, "xc_evtchn_bind_interdomain failed\n");
+xen_be_printf(xendev, 0, "xenevtchn_bind_interdomain failed\n");
return -1;
}
xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
xen_be_evtchn_event, NULL, xendev);
return 0;
}
@@ -757,15 +758,15 @@ void xen_be_unbind_evtchn(struct XenDevice *xendev)
if (xendev->local_port == -1) {
return;
}
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
-xc_evtchn_unbind(xendev->evtchndev, xendev->local_port);
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
+xenevtchn_unbind(xendev->evtchndev, xendev->local_port);
xen_be_printf(xendev, 2, "unbind evtc
[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v7 3/4] qemu-xen-traditional: Add libxencall to rpath-link
libxenctrl links against this library Signed-off-by: Ian Campbell Acked-by: Ian Jackson --- v3: Library moved to tools/libs --- xen-hooks.mak | 1 + 1 file changed, 1 insertion(+) diff --git a/xen-hooks.mak b/xen-hooks.mak index 179a6b7..229d642 100644 --- a/xen-hooks.mak +++ b/xen-hooks.mak @@ -25,6 +25,7 @@ LIBS += -L$(XEN_ROOT)/tools/libs/gnttab -lxengnttab LIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog +LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/call LDFLAGS := $(CFLAGS) $(LDFLAGS) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 22/29] tools/libs/call: Update some log messages to not refer to xc.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libs/call/linux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index 55e1e83..3641e41 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -94,7 +94,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t npages)
p = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
if ( p == MAP_FAILED )
{
-PERROR("xc_alloc_hypercall_buffer: mmap failed");
+PERROR("alloc_pages: mmap failed");
return NULL;
}
@@ -103,7 +103,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t
npages)
rc = madvise(p, npages * PAGE_SIZE, MADV_DONTFORK);
if ( rc < 0 )
{
-PERROR("xc_alloc_hypercall_buffer: madvise failed");
+PERROR("alloc_pages: madvise failed");
goto out;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 13/29] tools: Refactor foreign memory mapping into libxenforeignmemory
libxenforeignmemory will provide a stable API and ABI for mapping
foreign domain memory (subject to appropriate privileges).
The new library exposes an interface equivalent to
xc_map_foreign_memory_bulk, which all the other
xc_map_foreign_memory_* functions (which remain in libxc) are
implemented in terms of.
Upon request (via #define XC_WANT_COMPAT_MAP_FOREIGN_API) libxenctrl
will provide a compat API for the old names. This is used by qemu-xen
and qemu-trad as well as various in tree things (which required
de-dupping various #includes in some too to get the #define before the
first).
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
Acked-by: Ian Jackson
---
Must be applied with:
- "qemu-xen-traditional: qemu-xen-traditional: Add
libxenforeignmemory to rpath-link" and a corresponding QEMU_TAG
update folded here.
- "mini-os: mini-os: Include libxenforeignmemory with libxc" and a
corresponding bump to MINIOS_UPSTREAM_REVISION folded in here.
v5: Allow close(NULL)
v6: Define XC_WANT_COMPAT_MAP_FOREIGN_API for xen-mceinj.c and memshrtool.c
Fix typo in type name in compat.c, and get the functions names to
match.
Use an osdep layer for _map, to allow for future common code.
v7: Correct comment in compat.h #error due to switch to osdep layer
for map in v6
Added mk-headers-$(XEN_TARGET_ARCH) build dependency instead of
open coding the recursion.
---
.gitignore | 2 +
stubdom/Makefile | 17 +++-
tools/Makefile | 2 +
tools/Rules.mk | 11 ++-
tools/console/daemon/utils.c | 1 -
tools/console/daemon/utils.h | 1 +
tools/libs/Makefile| 1 +
tools/libs/foreignmemory/Makefile | 67 +
tools/libs/foreignmemory/compat.c | 72 ++
tools/libs/foreignmemory/core.c| 84 +
.../foreignmemory/freebsd.c} | 33 +++
.../libs/foreignmemory/include/xenforeignmemory.h | 71 ++
tools/libs/foreignmemory/libxenforeignmemory.map | 7 ++
.../foreignmemory/linux.c} | 70 ++
tools/libs/foreignmemory/minios.c | 62
tools/libs/foreignmemory/netbsd.c | 105 +
tools/libs/foreignmemory/private.h | 53 +++
tools/libs/foreignmemory/solaris.c | 93 ++
tools/libxc/Makefile | 8 +-
tools/libxc/include/xenctrl.h | 26 -
tools/libxc/include/xenctrl_compat.h | 36 +++
tools/libxc/xc_foreign_memory.c| 49 +-
tools/libxc/xc_minios.c| 29 --
tools/libxc/xc_netbsd.c| 73 --
tools/libxc/xc_private.c | 13 +--
tools/libxc/xc_private.h | 11 ++-
tools/libxc/xc_solaris.c | 73 --
tools/libxc/xc_sr_restore.c| 4 +-
tools/libxc/xc_sr_save.c | 4 +-
tools/libxc/xg_private.h | 3 +-
tools/libxl/libxl_internal.h | 1 +
tools/misc/xen-mfndump.c | 1 +
tools/ocaml/libs/xc/xenctrl_stubs.c| 1 +
tools/python/xen/lowlevel/xc/xc.c | 2 +
tools/tests/mce-test/tools/xen-mceinj.c| 1 +
tools/tests/mem-sharing/memshrtool.c | 1 +
tools/xenmon/xenbaked.c| 1 +
tools/xenpaging/pagein.c | 1 -
tools/xenpaging/xenpaging.c| 1 -
tools/xenpaging/xenpaging.h| 2 +
tools/xenstore/xenstored_core.c| 1 -
tools/xenstore/xenstored_core.h| 1 +
tools/xentrace/xenctx.c| 3 +-
tools/xentrace/xentrace.c | 1 +
44 files changed, 766 insertions(+), 333 deletions(-)
create mode 100644 tools/libs/foreignmemory/Makefile
create mode 100644 tools/libs/foreignmemory/compat.c
create mode 100644 tools/libs/foreignmemory/core.c
rename tools/{libxc/xc_freebsd_osdep.c => libs/foreignmemory/freebsd.c} (76%)
create mode 100644 tools/libs/foreignmemory/include/xenforeignmemory.h
create mode 100644 tools/libs/foreignmemory/libxenforeignmemory.map
rename tools/{libxc/xc_linux_osdep.c => libs/foreignmemory/linux.c} (83%)
create mode 100644 tools/libs/foreignmemory/minios.c
create mode 100644 tools/libs/foreignmemory/netbsd.c
create mode 100644 tools/libs/foreignmemory/private.h
create mode 100644 tools/libs/foreignmemory/solaris.c
diff --git a/.gitignore
[Xen-devel] [PATCH MINI-OS v7 4/4] mini-os: Include libxenforeignmemory with libxc
libxenforeignmemory has just been split out from libxc. From mini-os's point of view we don't care about the distinction, so keep things simple by just including libxenforeignmemory if libxc is enabled. Signed-off-by: Ian Campbell Acked-by: Samuel Thibault Acked-by: Wei Liu --- v2: Adjust for libs/$lib layout. --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index c900540..cfe015a 100644 --- a/Makefile +++ b/Makefile @@ -169,6 +169,7 @@ APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog -whole-ar APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn -whole-archive -lxenevtchn -no-whole-archive APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab -whole-archive -lxengnttab -no-whole-archive APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call -whole-archive -lxencall -no-whole-archive +APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory -whole-archive -lxenforeignmemory -no-whole-archive APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive -lxenguest -lxenctrl -no-whole-archive endif APP_LDLIBS += -lpci -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 16/29] tools/libs/foreignmemory: Mention restrictions on fork in docs.
Signed-off-by: Ian Campbell --- v6: Also discuss recovering the memory. v7: Further clarifications regarding forking based on ML discussions. (Dropped Wei's ack) --- .../libs/foreignmemory/include/xenforeignmemory.h | 33 +- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h b/tools/libs/foreignmemory/include/xenforeignmemory.h index 87f72fd..36f3753 100644 --- a/tools/libs/foreignmemory/include/xenforeignmemory.h +++ b/tools/libs/foreignmemory/include/xenforeignmemory.h @@ -32,13 +32,44 @@ typedef struct xentoollog_logger xentoollog_logger; typedef struct xenforeignmemory_handle xenforeignmemory_handle; /* - * Return a handle onto the hypercall driver. Logs errors. + * Return a handle onto the foreign memory mapping driver. Logs errors. + * + * Note: After fork(2) a child process must not use any opened + * foreignmemory handle inherited from their parent, nor access any + * grant mapped areas associated with that handle. + * + * The child must open a new handle if they want to interact with + * foreignmemory. + * + * Calling exec(2) in a child will safely (and reliably) reclaim any + * resources which were allocated via a xenforeignmemory_handle in the + * parent. + * + * A child which does not call exec(2) may safely call + * xenforeignmemory_close() on a xenforeignmemory_handle inherited + * from their parent. This will attempt to reclaim any resources + * associated with that handle. Note that in some implementations this + * reclamation may not be completely effective, in this case any + * affected resources remain allocated. + * + * Calling xenforeignmemory_close() is the only safe operation on a + * xenforeignmemory_handle which has been inherited. */ xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger, unsigned open_flags); /* * Close a handle previously allocated with xenforeignmemory_open(). + * + * Under normal circumstances (i.e. not in the child after a fork) + * xenforeignmemory_unmap() should be used on all mappings allocated + * by xenforeignmemory_map() prior to closing the handle in order to + * free up resources associated with those mappings. + * + * This is the only function which may be safely called on a + * xenforeignmemory_handle in a child after a + * fork. xenforeignmemory_unmap() must not be called under such + * circumstances. */ int xenforeignmemory_close(xenforeignmemory_handle *xmem); -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH MINI-OS v7 2/4] mini-os: Include libxengnttab with libxc
libxengnttab has just been split out from libxc. From mini-os's point of view we don't care about the distinction, so keep things simple by just including libxengnttab if libxc is enabled. Signed-off-by: Ian Campbell Acked-by: Samuel Thibault Acked-by: Wei Liu --- v2: Adjust for libs/$lib layout. --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index d1d8dc4..521f647 100644 --- a/Makefile +++ b/Makefile @@ -167,6 +167,7 @@ ifeq ($(libc),y) ifeq ($(CONFIG_XC),y) APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog -whole-archive -lxentoollog -no-whole-archive APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn -whole-archive -lxenevtchn -no-whole-archive +APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab -whole-archive -lxengnttab -no-whole-archive APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive -lxenguest -lxenctrl -no-whole-archive endif APP_LDLIBS += -lpci -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 29/29] HACK: Update Config.mk to pull all the right bits from my xenbits trees
v4: Config.mk instead of .config --- Config.mk | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/Config.mk b/Config.mk index 8fc7767..5472d45 100644 --- a/Config.mk +++ b/Config.mk @@ -1,5 +1,3 @@ -# -*- mode: Makefile; -*- - ifeq ($(filter /%,$(XEN_ROOT)),) $(error XEN_ROOT must be absolute) endif @@ -242,22 +240,22 @@ endif ifeq ($(GIT_HTTP),y) OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git -QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-xen.git -QEMU_TRADITIONAL_URL ?= http://xenbits.xen.org/git-http/qemu-xen-traditional.git +QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/qemu-xen.git +QEMU_TRADITIONAL_URL ?= http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/qemu-xen-traditional.git SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git -MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/mini-os.git +MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/mini-os.git else OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git -QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-xen.git -QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-traditional.git +QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git +QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git -MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git +MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git endif OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d -QEMU_UPSTREAM_REVISION ?= master -MINIOS_UPSTREAM_REVISION ?= d25773c8afa2f4dbbb466116daeb60159ddd22bd -# Thu Dec 3 11:23:25 2015 + -# mini-os: Include libxentoollog with libxc +QEMU_UPSTREAM_REVISION ?= origin/v7 +MINIOS_UPSTREAM_REVISION ?= origin/v7 +# Mon Nov 23 16:34:31 2015 + +# Add a .gitignore SEABIOS_UPSTREAM_REVISION ?= rel-1.9.0 # Tue Nov 17 09:18:44 2015 -0500 @@ -266,9 +264,9 @@ SEABIOS_UPSTREAM_REVISION ?= rel-1.9.0 ETHERBOOT_NICS ?= rtl8139 8086100e -QEMU_TRADITIONAL_REVISION ?= 9fad9ed285835caef64bb8dab352e287ad8538c2 -# Thu Dec 3 11:23:16 2015 + -# qemu-xen-traditional: Use xentoollog as a separate library +QEMU_TRADITIONAL_REVISION ?= origin/v7 +# Tue Mar 11 10:19:23 2014 + +# block-vvfat: fix resource leaks in read_directory() # Specify which qemu-dm to use. This may be `ioemu' to use the old # Mercurial in-tree version, or a local directory, or a git URL. -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 28/29] tools: Update CFLAGS for qemu-xen to allow it to use new libraries
This means adding -L for libxen{evtchn,gnttab,foreignmemory} so that
it can link them directly (rather than using the libxenctrl compat
layer exposed via -rpath-link). Also add -I for libxenforeignmemory.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/tools/Makefile b/tools/Makefile
index c03f6db..3575f16 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -255,12 +255,16 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
-I$(XEN_ROOT)/tools/libs/toollog/include \
-I$(XEN_ROOT)/tools/libs/evtchn/include \
-I$(XEN_ROOT)/tools/libs/gnttab/include \
+ -I$(XEN_ROOT)/tools/libs/foreignmemory/include \
-I$(XEN_ROOT)/tools/libxc/include \
-I$(XEN_ROOT)/tools/xenstore/include \
-I$(XEN_ROOT)/tools/xenstore/compat/include \
$(EXTRA_CFLAGS_QEMU_XEN)" \
--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
-L$(XEN_ROOT)/tools/xenstore \
+ -L$(XEN_ROOT)/tools/libs/evtchn \
+ -L$(XEN_ROOT)/tools/libs/gnttab \
+ -L$(XEN_ROOT)/tools/libs/foreignmemory \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/evtchn \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/gnttab \
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH MINI-OS v7 0/4] Begin to disentangle libxenctrl and provide some stable libraries
We intend to stabilise some parts of the libxenctrl interface by splitting out some functionality into separate stable libraries. This is the mini-os part of the first phase of that change. This mail is (or is intended to be) a reply to a "0/" super-intro mail covering all of the related patch series and which contains more details. Ian Campbell (4): mini-os: Include libxenevtchn with libxc mini-os: Include libxengnttab with libxc mini-os: Include libxencall with libxc mini-os: Include libxenforeignmemory with libxc Makefile | 4 1 file changed, 4 insertions(+) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v7 4/4] qemu-xen-traditional: Add libxenforeignmemory to rpath-link
libxenctrl links against this library. Also, request the compat xc_map_foreign API from libxc. Signed-off-by: Ian Campbell Acked-by: Ian Jackson --- v3: Library moved to tools/libs/ --- xen-hooks.mak | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen-hooks.mak b/xen-hooks.mak index 229d642..c1ea4be 100644 --- a/xen-hooks.mak +++ b/xen-hooks.mak @@ -1,6 +1,7 @@ CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/toollog/include CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/evtchn/include CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/gnttab/include +CPPFLAGS+= -DXC_WANT_COMPAT_MAP_FOREIGN_API CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc/include CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/include CPPFLAGS+= -I$(XEN_ROOT)/tools/include @@ -26,6 +27,7 @@ LIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/call +LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/foreignmemory LDFLAGS := $(CFLAGS) $(LDFLAGS) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 21/29] tools/libs/gnttab: Extensive updates to API documentation.
In particular around error handling, behaviour on fork and the unmap
notification mechanism.
Behaviour of xengnttab_map_*grant_refs and xengntshr_share_pages on
partial failure has been confirmed/inferred (by inspection) on Linux
and Mini-os (the only two known implementations. Likewise the
behaviour of the notification mechanism has been confirmed/inferred
(by inspection) of the Linux implementation (currently the only
implementation) and libvchan (primary known user).
These updates are not folded into "tools: Refactor
/dev/xen/gnt{dev,shr} wrappers into libxengnttab." to try and reduce
the amount of non-movement changes in that patch.
While I'm not convinced by javadoc/doxygen cause the existing comments
which appear to use that syntax to have the appropriate /** marker.
Also fix a typo in a code comment.
Signed-off-by: Ian Campbell
Reviewed-by: Daniel De Graaf
Cc: Daniel De Graaf
---
v7: Typo.
Updates based on Ian Jackson's review.
Even more updates to the discussion of forking based on ML
discussion.
v6: Rewrapped a comment.
Incorported much review from Ian on the API, retitled (was:
"tools/libs/gnttab: Review and update doc comments.") and dropped
acks
---
tools/libs/gnttab/include/xengnttab.h | 201 +-
tools/libs/gnttab/linux.c | 12 +-
2 files changed, 181 insertions(+), 32 deletions(-)
diff --git a/tools/libs/gnttab/include/xengnttab.h
b/tools/libs/gnttab/include/xengnttab.h
index 1e07672..7bf8462 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -31,28 +31,124 @@
typedef struct xentoollog_logger xentoollog_logger;
/*
+ * PRODUCING AND CONSUMING GRANT REFERENCES
+ *
+ *
+ * The xengnttab library contains two distinct interfaces, each with
+ * their own distinct handle type and entry points. The represent the
+ * two sides of the grant table interface, producer (gntshr) and
+ * consumer (gnttab).
+ *
+ * The xengnttab_* interfaces take a xengnttab_handle and provide
+ * mechanisms for consuming (i.e. mapping or copying to/from) grant
+ * references provided by a peer.
+ *
+ * The xengntshr_* interfaces take a xengntshr_handle and provide a
+ * mechanism to produce grantable memory and grant references to that
+ * memory, which can be handed to some peer.
+ *
+ * UNMAP NOTIFICATION
+ * ==
+ *
+ * The xengnt{tab,shr}_*_notify interfaces implement a cooperative
+ * interface which is intended to allow the underlying kernel
+ * interfaces to attempt to notify the peer to perform graceful
+ * teardown upon failure (i.e. crash or exit) of the process on their
+ * end.
+ *
+ * These interfaces operate on a single page only and are intended for
+ * use on the main shared-ring page of a protocol. It is assumed that
+ * on teardown both ends would automatically teardown all grants
+ * associated with the protocol in addition to the shared ring itself.
+ *
+ * Each end is able to optionally nominate a byte offset within the
+ * shared page or an event channel or both. On exit of the process the
+ * underlying kernel driver will zero the byte at the given offset and
+ * signal the event channel.
+ *
+ * The event channel can be the same event channel used for regular
+ * ring progress notifications, or may be a dedicated event channel.
+ *
+ * Both ends may share the same notification byte offset within the
+ * shared page, or may have dedicated "client" and "server" status
+ * bytes.
+ *
+ * Since the byte is cleared on shutdown the protocol must use 0 as
+ * the "closed/dead" status, but is permitted to use any other non-0
+ * values to indicate various other "live" states (waiting for
+ * connection, connected, etc).
+ *
+ * Both ends are permitted to modify (including clear) their
+ * respective status bytes and to signal the event channel themselves
+ * from userspace.
+ *
+ * Depending on the mechanisms which have been registered an
+ * the peer may receive a shutdown notification as:
+ *
+ * - An event channel notification on a dedicated event channel
+ * - Observation of the other ends's status byte being cleared
+ * (whether in response to an explicit notification or in the
+ * course of normal operation).
+ *
+ * The mechanism should be defined as part of the specific ring
+ * protocol.
+ *
+ * Upon receiving notification of the peer is expected to teardown any
+ * resources (and in particular any grant mappings) in a timely
+ * manner.
+ *
+ * NOTE: this protocol is intended to allow for better error behaviour
+ * and recovery between two cooperating peers. It does not cover the
+ * case of a malivious peer who may continue to hold resources open.
+ */
+
+/*
* Grant Table Interface (making use of grants from other domains)
*/
typedef struct xengntdev_handle xengnttab_handle;
/*
- * Note:
- * After fork a child process must not use any opened xc gnttab
- * handle inherited from their parent. T
[Xen-devel] [PATCH QEMU-XEN v7 1/8] xen_console: correctly cleanup primary console on teardown.
All of the work in con_disconnect applies to the primary console case
(when xendev->dev is NULL). Therefore remove the early check and bail
and allow it to fall through. All of the existing code is correctly
conditional already.
The ->dev and ->gnttabdev handles are either both set or neither. For
consistency with con_initialise() with to the former here too.
With this con_initialise and con_disconnect now mirror each other.
Fix up a hard tab in the function while editing.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
---
v4: New patch based on feedback to "xen: Switch uses of
xc_map_foreign_bulk to use libxenforeignmemory API."
---
hw/char/xen_console.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index eb7f450..63ade33 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -265,9 +265,6 @@ static void con_disconnect(struct XenDevice *xendev)
{
struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
-if (!xendev->dev) {
-return;
-}
if (con->chr) {
qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
qemu_chr_fe_release(con->chr);
@@ -275,12 +272,12 @@ static void con_disconnect(struct XenDevice *xendev)
xen_be_unbind_evtchn(&con->xendev);
if (con->sring) {
-if (!xendev->gnttabdev) {
+if (!xendev->dev) {
munmap(con->sring, XC_PAGE_SIZE);
} else {
xc_gnttab_munmap(xendev->gnttabdev, con->sring, 1);
}
- con->sring = NULL;
+con->sring = NULL;
}
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 24/29] tools/libs/call: Avoid xc_memalign in netbsd and solaris backends
These are already arch specific, so just use the appropriate
interfaces (as determined by looking at the xc_memalign backend).
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libs/call/netbsd.c | 4 ++--
tools/libs/call/solaris.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libs/call/netbsd.c b/tools/libs/call/netbsd.c
index 2aa02f1..e96fbf1 100644
--- a/tools/libs/call/netbsd.c
+++ b/tools/libs/call/netbsd.c
@@ -74,8 +74,8 @@ void *osdep_alloc_hypercall_buffer(xencall_handle *xcall,
size_t npages)
size_t size = npages * XC_PAGE_SIZE;
void *p;
-p = xc_memalign(xcall, XC_PAGE_SIZE, size);
-if (!p)
+ret = posix_memalign(&p, XC_PAGE_SIZE, size);
+if ( ret != 0 || !p )
return NULL;
if ( mlock(p, size) < 0 )
diff --git a/tools/libs/call/solaris.c b/tools/libs/call/solaris.c
index 945d867..5aa330e 100644
--- a/tools/libs/call/solaris.c
+++ b/tools/libs/call/solaris.c
@@ -71,7 +71,7 @@ int osdep_xencall_close(xencall_handle *xcall)
void *osdep_alloc_hypercall_buffer(xencall_handle *xcall, size_t npages)
{
-return xc_memalign(xcall, XC_PAGE_SIZE, npages * XC_PAGE_SIZE);
+return memalign(XC_PAGE_SIZE, npages * XC_PAGE_SIZE);
}
void osdep_free_hypercall_buffer(xencall_handle *xcall, void *ptr,
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 18/29] tools/libs/foreignmemory: pull array length argument to map forward
By having the "num" argument before the page and error arrays we can
potentially use a variable-length-array argument ("int pages[num]") in
the function prototype.
However VLAs are a C99 feature and we are currently targetting C89 and
later, so we don't actually make use of this here, merely arrange that
we can switch to VLAs in the future without changing the function ABI.
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
Acked-by: Ian Jackson
---
v6: New
---
tools/libs/foreignmemory/compat.c | 4 ++--
tools/libs/foreignmemory/core.c | 5 +++--
tools/libs/foreignmemory/freebsd.c | 4 ++--
tools/libs/foreignmemory/include/xenforeignmemory.h | 4 ++--
tools/libs/foreignmemory/linux.c| 3 ++-
tools/libs/foreignmemory/minios.c | 3 ++-
tools/libs/foreignmemory/private.h | 3 ++-
tools/libxc/xc_foreign_memory.c | 4 ++--
tools/libxc/xc_sr_restore.c | 2 +-
tools/libxc/xc_sr_save.c| 2 +-
10 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/tools/libs/foreignmemory/compat.c
b/tools/libs/foreignmemory/compat.c
index 039297c..b79ec1a 100644
--- a/tools/libs/foreignmemory/compat.c
+++ b/tools/libs/foreignmemory/compat.c
@@ -22,8 +22,8 @@
#include "private.h"
void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, size_t num)
+ uint32_t dom, int prot, size_t num,
+ const xen_pfn_t arr[/*num*/], int
err[/*num*/])
{
xen_pfn_t *pfn;
unsigned int i;
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index 4e0541f..cfb0a73 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -64,7 +64,8 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem)
void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, size_t num)
+ size_t num,
+ const xen_pfn_t arr[/*num*/], int err[/*num*/])
{
void *ret;
int *err_to_free = NULL;
@@ -75,7 +76,7 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
if ( err == NULL )
return NULL;
-ret = osdep_xenforeignmemory_map(fmem, dom, prot, arr, err, num);
+ret = osdep_xenforeignmemory_map(fmem, dom, prot, num, arr, err);
if ( ret == 0 && err_to_free )
{
diff --git a/tools/libs/foreignmemory/freebsd.c
b/tools/libs/foreignmemory/freebsd.c
index ed26ebb..703754f 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -84,8 +84,8 @@ int osdep_xenforeignmemory_close(xenforeignmemory_handle
*fmem)
void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err,
- size_t num)
+ size_t num,
+ const xen_pfn_t arr[/*num*/], int
err[/*num*/])
{
int fd = fmem->fd;
privcmd_mmapbatch_t ioctlx;
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index b162dca..d75f946 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -104,8 +104,8 @@ int xenforeignmemory_close(xenforeignmemory_handle *xmem);
* of @err indicating failure to map every page.
*/
void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
- int prot, const xen_pfn_t *arr, int *err,
- size_t pages);
+ int prot, size_t pages,
+ const xen_pfn_t arr[/*pages*/], int err[/*pages*/]);
/*
* Unmap a mapping previous created with xenforeignmemory_map().
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 6620391..32b6def 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -161,7 +161,8 @@ out:
void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, size_t num)
+ size_t num,
+ const xen_pfn_t arr[/*num*/], int
err[/*num*/])
{
int fd = fmem->fd;
privcmd_mmapbatch_v2_t ioctlx;
diff --git a/tools/libs/foreignmemory/minios.c
b/tools/libs/foreignmemory/minios.c
index bdc1239..ca5ba71 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -41,
[Xen-devel] [PATCH XEN v7 23/29] tools/libs/call: Describe return values and error semantics for xencall*
This behaviour has been confirmed by inspection on:
- Linux
- NetBSD & FreeBSD (NB: hcall->retval is the hypercall return value
only for values >= 0. For negative values the underlying privcmd
driver translates the value from Xen to {Net,Free}BSD errno space
and returns it as the result of the ioctl, which becomes
ret=-1/errno=EFOO in userspace)
- MiniOS (which takes care of errno in this library)
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
Acked-by: Ian Jackson
Cc: Roger Pau Monné
---
v7: Noted NetBSD behaviour
v6: New patch
---
tools/libs/call/include/xencall.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/libs/call/include/xencall.h
b/tools/libs/call/include/xencall.h
index 0d91aa8..3f325f0 100644
--- a/tools/libs/call/include/xencall.h
+++ b/tools/libs/call/include/xencall.h
@@ -46,6 +46,21 @@ int xencall_close(xencall_handle *xcall);
/*
* Call hypercalls with varying numbers of arguments.
+ *
+ * On success the return value of the hypercall is the return value of
+ * the xencall function. On error these functions set errno and
+ * return -1.
+ *
+ * The errno values will be either:
+ * - The Xen hypercall error return (from xen/include/public/errno.h)
+ * translated into the corresponding local value for that POSIX error.
+ * - An errno value produced by the OS driver or the library
+ * implementation. Such values may be defined by POSIX or by the OS.
+ *
+ * Note that under some circumstances it will not be possible to tell
+ * whether an error came from Xen or from the OS/library.
+ *
+ * These functions never log.
*/
int xencall0(xencall_handle *xcall, unsigned int op);
int xencall1(xencall_handle *xcall, unsigned int op,
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH XEN v7 20/29] tools/libs: Clean up hard tabs.
These were wrong in the context of libxc before this code was
extracted, clean them up.
Also add some emacs magic blocks
Signed-off-by: Ian Campbell
Acked-by: Wei Liu
---
tools/libs/call/buffer.c | 4 ++--
tools/libs/call/core.c| 2 +-
tools/libs/call/minios.c | 4 ++--
tools/libs/evtchn/minios.c| 28 ++--
tools/libs/evtchn/netbsd.c| 12 ++--
tools/libs/foreignmemory/freebsd.c| 2 +-
tools/libs/foreignmemory/minios.c | 6 +++---
tools/libs/foreignmemory/netbsd.c | 2 +-
tools/libs/foreignmemory/private.h| 2 +-
tools/libs/foreignmemory/solaris.c| 12 +++-
tools/libs/gnttab/include/xengnttab.h | 4 ++--
tools/libs/gnttab/linux.c | 6 +++---
tools/libs/toollog/xtl_logger_stdio.c | 2 +-
13 files changed, 48 insertions(+), 38 deletions(-)
diff --git a/tools/libs/call/buffer.c b/tools/libs/call/buffer.c
index 1a1b27a..2d8fc29 100644
--- a/tools/libs/call/buffer.c
+++ b/tools/libs/call/buffer.c
@@ -20,7 +20,7 @@
#include "private.h"
#define DBGPRINTF(_m...) \
- xtl_log(xcall->logger, XTL_DEBUG, -1, "xencall:buffer", _m)
+xtl_log(xcall->logger, XTL_DEBUG, -1, "xencall:buffer", _m)
#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
@@ -86,7 +86,7 @@ static int cache_free(xencall_handle *xcall, void *p, size_t
nr_pages)
xcall->buffer_current_allocations--;
if ( nr_pages == 1 &&
-xcall->buffer_cache_nr < BUFFER_CACHE_SIZE )
+ xcall->buffer_cache_nr < BUFFER_CACHE_SIZE )
{
xcall->buffer_cache[xcall->buffer_cache_nr++] = p;
rc = 1;
diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
index a342871..bbf88de 100644
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -19,7 +19,7 @@
xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags)
{
- xencall_handle *xcall = malloc(sizeof(*xcall));
+xencall_handle *xcall = malloc(sizeof(*xcall));
int rc;
if (!xcall) return NULL;
diff --git a/tools/libs/call/minios.c b/tools/libs/call/minios.c
index 3bee7be..f04688f 100644
--- a/tools/libs/call/minios.c
+++ b/tools/libs/call/minios.c
@@ -50,8 +50,8 @@ int osdep_hypercall(xencall_handle *xcall,
privcmd_hypercall_t *hypercall)
ret = HYPERVISOR_multicall(&call, 1);
if (ret < 0) {
- errno = -ret;
- return -1;
+errno = -ret;
+return -1;
}
if ((long) call.result < 0) {
errno = - (long) call.result;
diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
index b839cd0..b4b5f14 100644
--- a/tools/libs/evtchn/minios.c
+++ b/tools/libs/evtchn/minios.c
@@ -103,8 +103,8 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t
port)
ret = notify_remote_via_evtchn(port);
if (ret < 0) {
- errno = -ret;
- ret = -1;
+errno = -ret;
+ret = -1;
}
return ret;
}
@@ -138,16 +138,16 @@ evtchn_port_or_error_t
xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int do
assert(get_current() == main_thread);
port_info = port_alloc(fd);
if (port_info == NULL)
- return -1;
+return -1;
printf("xenevtchn_bind_unbound_port(%d)", domid);
ret = evtchn_alloc_unbound(domid, evtchn_handler, (void*)(intptr_t)fd,
&port);
printf(" = %d\n", ret);
if (ret < 0) {
- port_dealloc(port_info);
- errno = -ret;
- return -1;
+port_dealloc(port_info);
+errno = -ret;
+return -1;
}
port_info->bound = 1;
port_info->port = port;
@@ -166,16 +166,16 @@ evtchn_port_or_error_t
xenevtchn_bind_interdomain(xenevtchn_handle *xce, int dom
assert(get_current() == main_thread);
port_info = port_alloc(fd);
if (port_info == NULL)
- return -1;
+return -1;
printf("xenevtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
ret = evtchn_bind_interdomain(domid, remote_port, evtchn_handler,
(void*)(intptr_t)fd, &local_port);
printf(" = %d\n", ret);
if (ret < 0) {
- port_dealloc(port_info);
- errno = -ret;
- return -1;
+port_dealloc(port_info);
+errno = -ret;
+return -1;
}
port_info->bound = 1;
port_info->port = local_port;
@@ -208,15 +208,15 @@ evtchn_port_or_error_t
xenevtchn_bind_virq(xenevtchn_handle *xce, unsigned int v
assert(get_current() == main_thread);
port_info = port_alloc(fd);
if (port_info == NULL)
- return -1;
+return -1;
printf("xenevtchn_bind_virq(%d)", virq);
port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
if (port < 0) {
- port_dealloc(port_info);
- errno = -port;
- return -1;
+port_dealloc(port_info);
+errno = -port;
+return -1;
}
port_info->bound = 1;
port_info->port = port;
diff --git a/tools/libs/evtchn/n
[Xen-devel] [PATCH QEMU-XEN v7 4/8] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.
One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.
In preparation for this switch all uses of xc_map_foreign_range to
xc_map_foreign_pages. This is trivial because size was always
XC_PAGE_SIZE so the necessary adjustments are trivial:
* Pass &mfn (an array of length 1) instead of mfn. The function
takes a pointer to const, so there is no possibily of mfn changing
due to this change.
* Pass nr_pages=1 instead of size=XC_PAGE_SIZE
There is one wrinkle in xen_console.c:con_initialise() where
con->ring_ref is an int but can in some code paths (when !xendev->dev)
be treated as an mfn. I think this is an existing latent truncation
hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g.
amd64, both arm* variants). I'm unsure under what circumstances
xendev->dev can be NULL or if anything elsewhere ensures the value
fits into an int. For now I just use a temporary xen_pfn_t to in
effect upcast the pointer from int* to xen_pfn_t*.
In xenfb.c:common_bind we now explicitly launder the mfn into a
xen_pfn_t, so it has the correct type to be passed to
xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86.
Signed-off-by: Ian Campbell
Reviewed-by: Stefano Stabellini
---
v7: Correct type mismatch (int64 vs xen_pfn_t) on 32 bit x86 in
xenfb.c, by explicitly laundering via a xen_pfn_t variable.
v6: Switch to xc_map_foreign_pages rather than _bulk. Switching to
_bulk without checking the value of err[0] risked missing errors.
The new xenforeignmemory_map coming later in this series will
DTRT with err==NULL.
Dropped Stefano's Reviewed-by due to this change.
v4: Ran checkpatch, fixed all errors
Mention the const-ness of the mfn array in the commit log
fixup!xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
---
hw/char/xen_console.c | 8
hw/display/xenfb.c| 15 ---
xen-hvm.c | 14 +++---
3 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index ac1b324..3e8a57b 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -228,10 +228,10 @@ static int con_initialise(struct XenDevice *xendev)
con->buffer.max_capacity = limit;
if (!xendev->dev) {
-con->sring = xc_map_foreign_range(xen_xc, con->xendev.dom,
- XC_PAGE_SIZE,
- PROT_READ|PROT_WRITE,
- con->ring_ref);
+xen_pfn_t mfn = con->ring_ref;
+con->sring = xc_map_foreign_pages(xen_xc, con->xendev.dom,
+ PROT_READ|PROT_WRITE,
+ &mfn, 1);
} else {
con->sring = xengnttab_map_grant_ref(xendev->gnttabdev,
con->xendev.dom,
con->ring_ref,
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 5e324ef..4a597d7 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -95,23 +95,24 @@ struct XenFB {
static int common_bind(struct common *c)
{
-uint64_t mfn;
+uint64_t val;
+xen_pfn_t mfn;
-if (xenstore_read_fe_uint64(&c->xendev, "page-ref", &mfn) == -1)
+if (xenstore_read_fe_uint64(&c->xendev, "page-ref", &val) == -1)
return -1;
-assert(mfn == (xen_pfn_t)mfn);
+mfn = (xen_pfn_t)val;
+assert(val == mfn);
if (xenstore_read_fe_int(&c->xendev, "event-channel",
&c->xendev.remote_port) == -1)
return -1;
-c->page = xc_map_foreign_range(xen_xc, c->xendev.dom,
- XC_PAGE_SIZE,
- PROT_READ | PROT_WRITE, mfn);
+c->page = xc_map_foreign_pages(xen_xc, c->xendev.dom,
+ PROT_READ | PROT_WRITE, &mfn, 1);
if (c->page == NULL)
return -1;
xen_be_bind_evtchn(&c->xendev);
-xen_be_printf(&c->xendev, 1, "ring mfn %"PRIx64", remote-port %d,
local-port %d\n",
+xen_be_printf(&c->xendev, 1, "ring mfn %"PRI_xen_pfn", remote-port %d,
local-port %d\n",
mfn, c->xendev.remote_port, c->xendev.local_port);
return 0;
diff --git a/xen-hvm.c b/xen-hvm.c
index 6680782..2f4e109 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1240,8 +1240,9 @@ int xen_hvm_init(PCMachineState *pcms,
DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
-state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
- PROT_READ|PROT_WRITE, ioreq_pfn);
+state->shared_page = xc_map_foreign_pages(xen_xc, xen_domid,
+
