This run is configured for baseline tests only.
flight 38134 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 21 guest-start/debi
flight 62699 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62699/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 86cce64da95783fbc990934e75901cfadd768228
baseline version:
ovmf 63e1c23b225578efdaca714a81055eadb0a
On 10/07/2015 10:21 PM, Konrad Rzeszutek Wilk wrote:
Hey,
I was running some tools in which we would heavily do rescheduling
of events - and realized to my surprise that the event channels (and
the hypercall) would slow things down. If I used the vAPIC with its
IPI support (so no VMEXIT) I got m
flight 62695 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62695/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start.2fail blocked in 62118
test-amd64-i386-rumpuserxen-i38
On 10/08/2015 03:10 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Oct 06, 2015 at 05:24:22PM +0100, Ian Campbell wrote:
On Tue, 2015-10-06 at 18:14 +0200, Juergen Gross wrote:
The original motivation was to get rid of the "superpages" option when
building a pv-domU.
It's suffered rather from feat
Changes in v6:
- x86:
* remove unnecessary parameter in cdp_is_enabled function
* remove variable need_write and restruct code in psr_set_l3_cbm
- tools & docs:
* separate CBM headings in the output of xl psr-cat-show
* revert the numbers of SDM chapter in xl-psr.markdown
* XC_PSR_CAT_L3_
This is the xl/xc changes to support Intel Code/Data Prioritization.
CAT xl commands to set/get CBMs are extended to support CDP.
Add new CDP options with CAT commands in xl interface man page.
Add description of CDP in xl-psr.markdown.
Signed-off-by: He Chen
---
Changes in v6:
* separate CBM hea
CDP extends CAT and provides the capacity to control L3 code & data
cache. With CDP, one COS corresponds to two CMBs(code & data). cbm_type
is added to distinguish different CBM operations. Besides, new domctl
cmds are introdunced to support set/get CDP CBM. Some CAT functions to
operation CBMs are
Add boot parameter `psr=cdp` to enable CDP at boot time.
Intel Code/Data Prioritization (CDP) feature is based on CAT. Note that
cos_max would be half when CDP is on. struct psr_cat_cbm is extended to
support CDP operation. Extend psr_get_cat_l3_info sysctl to get CDP
status.
Signed-off-by: He Che
On Tue, Oct 06, 2015 at 05:24:22PM +0100, Ian Campbell wrote:
> On Tue, 2015-10-06 at 18:14 +0200, Juergen Gross wrote:
>
> > The original motivation was to get rid of the "superpages" option when
> > building a pv-domU.
>
> It's suffered rather from feature creep then, since removing that one
>
flight 62694 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62694/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254
test-armhf-armhf-xl
flight 62690 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail REGR. vs. 62318
Tests
This run is configured for baseline tests only.
flight 38132 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38132/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 16 guest-start/
flight 62686 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62686/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-qcow2 3 host-install(3) broken baseline untested
test-armhf-armhf-libvirt 6
On 10/07/2015 04:21 PM, Konrad Rzeszutek Wilk wrote:
under one parameter. Removes the xen_nopvspin parameter and
makes it part of the xen_nopv.
Signed-off-by: Konrad Rzeszutek Wilk
---
Documentation/kernel-parameters.txt | 15 +--
arch/x86/xen/enlighten.c| 50
Hi Konrad,
[auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore]
config: x86_64-randconfig-x016-201540 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86/
On 10/07/2015 02:32 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 07, 2015 at 01:53:01PM -0600, Jens Axboe wrote:
On 10/07/2015 01:26 PM, Konrad Rzeszutek Wilk wrote:
Hey Jens,
Please git pull an update branch to your 'for-4.3/drivers' branch (which
oddly I don't see does not have the previous
On Wed, Oct 07, 2015 at 01:53:01PM -0600, Jens Axboe wrote:
> On 10/07/2015 01:26 PM, Konrad Rzeszutek Wilk wrote:
> >Hey Jens,
> >
> >Please git pull an update branch to your 'for-4.3/drivers' branch (which
> >oddly I don't see does not have the previous pull?)
> >
> > git://git.kernel.org/pub/sc
Instead of using the event channels.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/smp.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3f4ebf0..d4f4560 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x
under one parameter. Removes the xen_nopvspin parameter and
makes it part of the xen_nopv.
Signed-off-by: Konrad Rzeszutek Wilk
---
Documentation/kernel-parameters.txt | 15 +--
arch/x86/xen/enlighten.c| 50 +
arch/x86/xen/spinlock.c
Hey,
I was running some tools in which we would heavily do rescheduling
of events - and realized to my surprise that the event channels (and
the hypercall) would slow things down. If I used the vAPIC with its
IPI support (so no VMEXIT) I got much much better performance.
Now this is an RFC becaus
On 10/07/2015 01:26 PM, Konrad Rzeszutek Wilk wrote:
Hey Jens,
Please git pull an update branch to your 'for-4.3/drivers' branch (which
oddly I don't see does not have the previous pull?)
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.3
which has two fixes -
Hey Jens,
Please git pull an update branch to your 'for-4.3/drivers' branch (which
oddly I don't see does not have the previous pull?)
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.3
which has two fixes - one where we use the Xen blockfront EFI driver and
don't
On 07/10/15 17:29, Julien Grall wrote:
> On 07/10/15 17:00, Ian Campbell wrote:
>> On Wed, 2015-10-07 at 16:48 +0100, Julien Grall wrote:
>>> On 07/10/15 16:38, Ian Campbell wrote:
On Wed, 2015-10-07 at 15:41 +0100, Julien Grall wrote:
> Note that with these changes, any read to those regi
On 07/10/15 18:26, Stefano Stabellini wrote:
> On Wed, 7 Oct 2015, Julien Grall wrote:
>> +/*
>> + * Store a ITARGETSR register in a convenient way and migrate the vIRQ
>> + * if necessary. This function only deals with ITARGETSR8 and onwards.
>> + *
>> + * Note the offset will be aligned to the ap
On Tue, Oct 6, 2015 at 2:38 PM, Jan Beulich wrote:
On 06.10.15 at 13:07, wrote:
>> A majority of developers express interests in trying a shorter release
>> cycle -- to change from 9 months to 6 months [0]. There are, however,
>> repercussions on how we manage stable and possible LTS release
On Tue, Oct 6, 2015 at 3:52 PM, Jan Beulich wrote:
On 06.10.15 at 16:09, wrote:
>> What do you propose when we regarding stable branches when we switch to
>> 6 months cycle?
>
> See the chicken-and-egg problem: I can't answer this, because the
> issues with the stable trees are the main reas
On 07/10/2015 14:04, "Konrad Rzeszutek Wilk"
wrote:
>On Wed, Oct 07, 2015 at 12:16:10PM +0100, Wei Liu wrote:
>> Hi all
>>
>> I'm pleased to announce that Xen 4.6 is released. As release manager I
>> would like to thank everyone who involved in the making of 4.6 release
>> (either in the form
flight 62685 linux-3.0 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62685/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 15418
Tests which are failing
On Wed, 7 Oct 2015, Julien Grall wrote:
> +/*
> + * Store a ITARGETSR register in a convenient way and migrate the vIRQ
> + * if necessary. This function only deals with ITARGETSR8 and onwards.
> + *
> + * Note the offset will be aligned to the appropriate boundary.
> + */
> +static void vgic_store
This run is configured for baseline tests only.
flight 38131 linux-arm-xen real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38131/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 9 debian-di-installf
>>> >> On October 01, 2015, at 5:09 PM wrote:
> At 15:05 + on 30 Sep (1443625549), Xu, Quan wrote:
> > >> >>> On September 29, 2015, at 5:12 PM, wrote:
> > Could I introduce a new typed reference which can only been deref in
> > QI interrupt handler(or associated tasklet)?? --(stop me, I al
Introduce a very simple (and dummy) domain loader to be used to load the
firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
executable the loader is fairly simple.
Since the order in which loaders are tested cannot be arranged, prevent the
current elfloader from trying to bo
On 07/10/15 17:00, Ian Campbell wrote:
> On Wed, 2015-10-07 at 16:48 +0100, Julien Grall wrote:
>> On 07/10/15 16:38, Ian Campbell wrote:
>>> On Wed, 2015-10-07 at 15:41 +0100, Julien Grall wrote:
Note that with these changes, any read to those registers will list
only
the target vCP
On 07/10/15 14:04, Julien Grall wrote:
> The type of the item in frame_list is xen_pfn_t which is not an unsigned
> long on ARM but an uint64_t.
Applied to for-linus-4.4, thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen
>>> On 14.09.15 at 04:32, wrote:
> --- a/tools/libxc/xc_pm.c
> +++ b/tools/libxc/xc_pm.c
> @@ -260,13 +260,14 @@ int xc_get_cpufreq_para(xc_interface *xch, int cpuid,
> }
> else
> {
> -user_para->cpuinfo_cur_freq = sys_para->cpuinfo_cur_freq;
> -user_para->cpuinfo_ma
On Wed, 2015-10-07 at 16:48 +0100, Julien Grall wrote:
> On 07/10/15 16:38, Ian Campbell wrote:
> > On Wed, 2015-10-07 at 15:41 +0100, Julien Grall wrote:
> > > Note that with these changes, any read to those registers will list
> > > only
> > > the target vCPU used by Xen. We think this is likely
On 07/10/15 16:38, Ian Campbell wrote:
> On Wed, 2015-10-07 at 15:41 +0100, Julien Grall wrote:
>> Note that with these changes, any read to those registers will list only
>> the target vCPU used by Xen. We think this is likely to be OK because the
>> GIC spec doesn't require to return exactly the
>>> On 14.09.15 at 04:32, wrote:
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
I think to make clear why this include is needed here it would be better
if you added the declaration of
On Wed, 2015-10-07 at 15:41 +0100, Julien Grall wrote:
> Note that with these changes, any read to those registers will list only
> the target vCPU used by Xen. We think this is likely to be OK because the
> GIC spec doesn't require to return exactly the value written and it can
> be seen as if we
>>> On 14.09.15 at 04:32, wrote:
> We simply grab the fundamental logic of the intel_pstate driver
> from Linux kernel, and customize it to Xen style. In the kernel,
> a user can adjust the limits via sysfs
> (limits.min_sysfs_pct/max_sysfs_pct). In Xen, the
> policy->limits.min_perf_pct/max_perf_
On Wed, 2015-10-07 at 16:20 +0100, Andrew Cooper wrote:
> On 07/10/15 16:16, Ian Campbell wrote:
> > On Wed, 2015-10-07 at 16:03 +0100, Andrew Cooper wrote:
> > > On 07/10/15 15:15, Ian Campbell wrote:
> > >
> > > What is the plan WRT fixing the existing APIs?
> > Which ones do you mean? The xc_ma
>>> On 14.09.15 at 04:32, wrote:
> We change to NULL the cpufreq_cpu_policy pointer after the call of
> cpufreq_driver->exit, because the pointer is still needed in
> intel_pstate_set_pstate().
>
> Signed-off-by: Wei Wang
> ---
> xen/drivers/cpufreq/cpufreq.c | 6 +++---
> xen/include/acpi
On Wednesday, October 07, 2015 12:52:02 PM Ian Campbell wrote:
> Applied.
>
> Mike, FWIW for singleton patches it is normally ok to dispense with the 0/1
> mail and to just send the patch by itself. If there is commentary which
> doesn't belong in the commit message you can put it below a "---" ma
Hi Dario,
Thank you very much for your reply!!! It is very nice of you :)
Yes I have checked the blog entry and that is actually where I started!
To define my "scheduling overhead", I think I should tell you what I am
trying to accomplish:
So I am currently using Xen 4.5 to help us understand m
On 07/10/15 16:16, Ian Campbell wrote:
> On Wed, 2015-10-07 at 16:03 +0100, Andrew Cooper wrote:
>> On 07/10/15 15:15, Ian Campbell wrote:
>>
>> What is the plan WRT fixing the existing APIs?
> Which ones do you mean? The xc_map_foreign_* which aren't moved here?
>
> My intention is to deprecate th
On Wed, 2015-10-07 at 16:08 +0100, George Dunlap wrote:
> On 07/10/15 15:15, Ian Campbell wrote:
> > It can trivially be replaced by xc_map_foreign_bulk which is the
> > interface I want to move to going forward. All in tree users are
> > trivially converted by supplying the appropriate error array
flight 62714 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62714/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Wed, 2015-10-07 at 16:03 +0100, Andrew Cooper wrote:
> On 07/10/15 15:15, Ian Campbell wrote:
>
> What is the plan WRT fixing the existing APIs?
Which ones do you mean? The xc_map_foreign_* which aren't moved here?
My intention is to deprecate them and switch everything over to the API
provid
On 10/07/2015 05:03 PM, George Dunlap wrote:
On 07/10/15 15:47, Juergen Gross wrote:
On 10/07/2015 04:35 PM, George Dunlap wrote:
On Wed, Oct 7, 2015 at 3:26 PM, Juergen Gross wrote:
On 10/07/2015 04:05 PM, Ian Campbell wrote:
On Wed, 2015-10-07 at 15:54 +0200, Juergen Gross wrote:
Hmm, t
On 06/10/15 15:55, Ian Campbell wrote:
> On Tue, 2015-10-06 at 15:39 +0100, Julien Grall wrote:
+csize = SZ_8K;
+}
+
+/*
+ * Check if the CPU interface and virtual CPU interface have the
+ * same size.
+ */
+if ( csize != vsize
On 07/10/15 15:15, Ian Campbell wrote:
> It can trivially be replaced by xc_map_foreign_bulk which is the
> interface I want to move to going forward. All in tree users are
> trivially converted by supplying the appropriate error array and
> adjusting the what error handling exists (which in many c
>>> On 14.09.15 at 04:32, wrote:
> Move the driver register function to
> the cpufreq.c.
... and remove the (unused) de-registration one.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 25/09/15 03:11, Chunyan Liu wrote:
> Add code to support pvusb in domain config file. One could specify
> usbctrl and usb in domain's configuration file and create domain,
> then usb controllers will be created and usb device would be attached
> to guest automatically.
>
> One could specify usb
On 07/10/15 15:15, Ian Campbell wrote:
What is the plan WRT fixing the existing APIs?
The two options are 1) Move to new libs then fix, or 2) Fix in tree then
move to pristine new libs.
Option 1) runs the risk of digging ourself a hole in the form of a
stable API. Option 2) seems like it would
On 07/10/15 15:47, Juergen Gross wrote:
> On 10/07/2015 04:35 PM, George Dunlap wrote:
>> On Wed, Oct 7, 2015 at 3:26 PM, Juergen Gross wrote:
>>> On 10/07/2015 04:05 PM, Ian Campbell wrote:
On Wed, 2015-10-07 at 15:54 +0200, Juergen Gross wrote:
> Hmm, technically all unassigne
On Wed, 2015-10-07 at 15:36 +0100, Andrew Cooper wrote:
> On 07/10/15 15:15, Ian Campbell wrote:
> > 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_
On Wed, 2015-10-07 at 10:57 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] standalone: do not rotate empty log
> files."):
> > By passing -n to savelog.
> >
> > In particular this prevents the creation of an empty $log.0 on first
> > use when $log doesn't exist.
>
> Acked-by: I
On Wed, 2015-10-07 at 15:42 +0100, Andrew Cooper wrote:
> > +.PHONY: install
> > +install: build
> > + $(INSTALL_DIR) $(DESTDIR)$(libdir)
> > + $(INSTALL_DIR) $(DESTDIR)$(includedir)
> > + $(INSTALL_SHLIB) libxentoollog.so.$(MAJOR).$(MINOR)
> > $(DESTDIR)$(libdir)
> > + $(INSTALL_DATA) lib
On 10/07/2015 04:35 PM, George Dunlap wrote:
On Wed, Oct 7, 2015 at 3:26 PM, Juergen Gross wrote:
On 10/07/2015 04:05 PM, Ian Campbell wrote:
On Wed, 2015-10-07 at 15:54 +0200, Juergen Gross wrote:
Hmm, technically all unassigned USB-devices are usable from Dom0. So why
not list them there.
Xen is currently directly storing the value of GICD_IPRIORITYR register
in the rank. This makes emulation of the register access very simple
but makes the code to get the priority for a given vIRQ more complex.
While the priority of an vIRQ is retrieved every time an vIRQ is injected
to the guest,
Xen is currently directly storing the value of GICD_ITARGETSR register
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given vIRQ more complex.
While the target vCPU of an vIRQ is ret
The guest may try to load data from the emulated MMIO region using
instructions with Sign-Extension (i.e ldrs*). Any use of one those,
will set the SSE bit (Syndrome Sign Extend) in the ISS (see B3-1433
in DDI 0406C.b).
Note that the bit can only be set for access size smaller than the
register si
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
On 07/10/15 15:15, Ian Campbell wrote:
> diff --git a/tools/libs/toollog/Makefile b/tools/libs/toollog/Makefile
> new file mode 100644
> index 000..bd12403
> --- /dev/null
> +++ b/tools/libs/toollog/Makefile
> @@ -0,0 +1,59 @@
> +XEN_ROOT = $(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.
Rather than letting each handler to retrieve the register used by the
I/O access, add a new parameter to pass the register in parameter.
This will help to implement generic register manipulation on I/O access
such as sign-extension and endianess.
Read handlers need to modify the value of the regi
Having in hand the index for the rank is very handy to avoid computing
it every time.
For now, use it when enabling/disabling the vIRQs rather than a formula
which is not obvious to understand.
Also drop the comments which were wrong because a shift by DABT_WORD
will not give the IRQ number but t
Hi all,
This series aims to fixc the 32-bit access on 64-bit register. Some guest
OS such as FreeBSD and Linux (only in ITS) use 32-bit access and will crash
at boot time.
I took the opportunity to go further and optimize the way Xen is storing
registers such as GICD_IPRIORITYR, GICD_ITARGETSR an
This typedef is a left-over of the previous MMIO emulation
implementation.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's Acked-by
Changes in v1:
- Patch added
---
xen/include/asm-arm/mmio.h | 1 -
1 file changed, 1 deletion(-)
diff
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's acked-by
Changes in v1:
- Patch added
---
xen/include/asm-arm/domain.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-ar
On 07/10/15 15:15, Ian Campbell wrote:
> 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.
>
>
>
> diff --gi
On Wed, Oct 7, 2015 at 3:26 PM, Juergen Gross wrote:
> On 10/07/2015 04:05 PM, Ian Campbell wrote:
>>
>> On Wed, 2015-10-07 at 15:54 +0200, Juergen Gross wrote:
>>
>>> Hmm, technically all unassigned USB-devices are usable from Dom0. So why
>>> not list them there.
>>
>>
>> I think you'd at least
On Wed, 2015-10-07 at 15:18 +0100, Ian Campbell wrote:
> On Wed, 2015-10-07 at 15:10 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH v3 0/] Begin to disentangle
> > libxenctrl and provide some stable libraries"):
> > > The tip of the xen.git branch contains an extra patch adding a
> > >
On 10/07/2015 04:05 PM, Ian Campbell wrote:
On Wed, 2015-10-07 at 15:54 +0200, Juergen Gross wrote:
Hmm, technically all unassigned USB-devices are usable from Dom0. So why
not list them there.
I think you'd at least want to distinguish USB devices available to dom0 as
via a PCI host controll
libxencall 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 libxencall if libxc is enabled.
Signed-off-by: Ian Campbell
---
v2: Adjust for libs/$lib layout.
---
Makefile | 1 +
1 file changed, 1 insertio
libxentoollog 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 libxentoollog if libxc is enabled.
Signed-off-by: Ian Campbell
---
v2: Adjust for libs/$lib layout.
---
Makefile | 1 +
1 file changed, 1 in
On Wed, 2015-10-07 at 15:10 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH v3 0/] Begin to disentangle
> libxenctrl and provide some stable libraries"):
> > The tip of the xen.git branch contains an extra patch adding a .config
> > into the tree which should get the correct things for the
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
---
v2: Adjust for libs/$lib layout.
---
Makefile | 1 +
1 file c
This has been split out of libxenctrl, so the build needs to be able
to find the header and the library. QEMU does not use xtl_* itself so
-rpath-link is sufficient to allow linking to libxenctrl.so (which
links against libxentoollog).
Signed-off-by: Ian Campbell
---
v3: Library moved to tools/li
Signed-off-by: Ian Campbell
---
tools/libs/foreignmemory/include/xenforeignmemory.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 1bcdf6a..5897fb8 100644
--
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 x
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 x
Until the previous patch this relied on xc_fd(), which was only
implemented for Xen 4.0 and earlier.
I stopped short of disabling this by default, although I think there's
a pretty strong argument for doing so.
Removing this support drops the use of a bunch of symbols from
libxenctrl, specificall
libxenctrl links against this library
Signed-off-by: Ian Campbell
---
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 +
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
---
v2: Adjust for libs/$lib layout.
---
Makefile | 1 +
1 file changed, 1 inse
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 incorre
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
---
tools/libs/call/netbsd.c | 4 ++--
tools/libs/call/solaris.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tool
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.
XXX consider combining into a single namespace (i.e. with
xe
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.
In tree libraries which link against other in tree libraries in a way
which is opaque to their callers need special handling, specifically
correct use of -Wl,-rpath-link for the recusively used libraries.
Currently this is rather simple, but up coming changes are going to
introduce transitive depe
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
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 fe
It can trivially be replaced by xc_map_foreign_bulk which is the
interface I want to move to going forward. All in tree users are
trivially converted by supplying the appropriate error array and
adjusting the what error handling exists (which in many cases is not
much).
This reduces the twist maze
Using the same rune as we use for the Xen public headers, except we do
not need stdint.h here and we use -pedantic too.
Signed-off-by: Ian Campbell
---
.gitignore | 2 ++
tools/Rules.mk | 8
tools/libs/evtchn/Makefile | 4 +++-
tools/libs/toollog/Makefile
Remove some stray xc references.
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
---
tools/libs/gnttab/include/xengnttab.h | 21 +++-
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
---
tools/Makefile | 4
1 file changed, 4 insertions(+)
d
libxenevtchn 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 libxenevtchn if libxc is enabled.
Signed-off-by: Ian Campbell
---
v2: Adjust for libs/$lib layout.
---
Makefile | 1 +
1 file changed, 1 inse
libxenctrl links against this library.
Also, request the compat xc_map_foreign API from libxc.
Signed-off-by: Ian Campbell
---
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
---
/dev/xen/gntdev related wrappers have been moved out of libxenctrl
into their own library.
Signed-off-by: Ian Campbell
---
v3: Library moved to tools/libs/
---
hw/xen_backend.c | 4 ++--
hw/xen_backend.h | 2 +-
hw/xen_common.h | 1 +
hw/xen_console.c | 4 ++--
hw/xen_disk.c| 24 +++
1 - 100 of 187 matches
Mail list logo
