>>> On 06.02.16 at 02:48, wrote:
> On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
> wrote:
>> From: "Luis R. Rodriguez"
>>
>> Here's a slew of build fixes as well as build warning fixes
>> required when using the latest build tools, at least gcc 5 and
>> binutils 2.25.0.
>
> One good reason
>>> On 05.02.16 at 16:45, wrote:
> El 5/2/16 a les 14:13, Jan Beulich ha escrit:
>> But
>> even then - wouldn't what I've read on the other thread mean
>> at least the filename should be put there (as kind of the first
>> command line element)?
>
> Really? I didn't get that impression at all, wha
>>> On 05.02.16 at 22:47, wrote:
>> Also is using "long" here really a good idea? Shouldn't we rather use
>> fixed width or ELF types?
>
> We can. It would look like this:
>
> struct xsplice_patch_func {
> const unsigned char *name;
> Elf64_Xword new_addr;
> Elf64_Xword old_addr;
>
Jan Beulich, on Tue 09 Feb 2016 01:14:13 -0700, wrote:
> >>> On 05.02.16 at 16:45, wrote:
> > El 5/2/16 a les 14:13, Jan Beulich ha escrit:
> >> But
> >> even then - wouldn't what I've read on the other thread mean
> >> at least the filename should be put there (as kind of the first
> >> command l
>>> On 06.02.16 at 23:35, wrote:
(Just to demonstrate the effect - please go right to the end.)
> On 1/14/16 3:47 PM, Konrad Rzeszutek Wilk wrote:
>> The implementation does not actually do any patching.
>>
>> It just adds the framework for doing the hypercalls,
>> keeping track of ELF payloads
>>> On 08.02.16 at 19:04, wrote:
> First -- and this isn't a blocker, but just a question (and sorry if
> it's been answered before) -- why have the "0 means I did it all, means I did it partially"? Why not just return the number of entries
> actually handled?
Because I view zero as the convent
Ian,
Some surprising behaviour of the libxlu disk spec parser is below...
On Mon, 2016-02-08 at 17:54 -0700, Jim Fehlig wrote:
> On 02/03/2016 07:53 PM, Jim Fehlig wrote:
> > On 02/03/2016 02:56 AM, Ian Campbell wrote:
> > > On Tue, 2016-02-02 at 15:06 -0700, Jim Fehlig wrote:
> > > > > And exten
On Mon, 2016-02-08 at 21:48 -0800, Suriyan Ramasami wrote:
> The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
> has been used to get all the 8 cores from the 2 clusters powered
> on.
> The Linux DTS for these odroid
On Fri, Feb 05, 2016 at 05:39:39PM -0800, Luis R. Rodriguez wrote:
> On Thu, Nov 19, 2015 at 3:06 PM, Luis R. Rodriguez
> wrote:
> > On Fri, Oct 9, 2015 at 12:34 AM, Jan Beulich wrote:
> > On 08.10.15 at 21:36, wrote:
> >>> Signed-off-by: Mark Pryor
> >>
> >> Without any description I canno
On 09/02/16 04:15, Doug Goldstein wrote:
> diff --git a/xen/include/asm-x86/vpmu.h b/xen/include/asm-x86/vpmu.h
> index 67e73dc..4750a1f 100644
> --- a/xen/include/asm-x86/vpmu.h
> +++ b/xen/include/asm-x86/vpmu.h
> @@ -89,10 +89,14 @@ static inline void vpmu_clear(struct vpmu_struct *vpmu)
> {
>
On 09/02/16 10:05, Andrew Cooper wrote:
> On 09/02/16 04:15, Doug Goldstein wrote:
>> diff --git a/xen/include/asm-x86/vpmu.h b/xen/include/asm-x86/vpmu.h
>> index 67e73dc..4750a1f 100644
>> --- a/xen/include/asm-x86/vpmu.h
>> +++ b/xen/include/asm-x86/vpmu.h
>> @@ -89,10 +89,14 @@ static inline vo
On Mon, Feb 08, 2016 at 04:59:46PM -0600, Chong Li wrote:
> On Mon, Feb 8, 2016 at 5:07 AM, Wei Liu wrote:
> >
> >
> > [...]
> > > >> +num_vcpus = max_vcpuid + 1;
> > > >> +GCNEW_ARRAY(vcpus, num_vcpus);
> > > >> +if (sched_rtds_validate_params(gc, scinfo->vcpus[0].period,
On Fri, 2016-02-05 at 10:08 +1100, Alex Braunegg wrote:
I'm copying the other tools maintainers as well as the x86 guys.
> Hi Ian,
>
> Below is the output requested:
>
> Guest Configuration:
>
> -
>
> builder='hvm'
> memory = 2048
>
El 9/2/16 a les 9:14, Jan Beulich ha escrit:
On 05.02.16 at 16:45, wrote:
>> El 5/2/16 a les 14:13, Jan Beulich ha escrit:
>>> But
>>> even then - wouldn't what I've read on the other thread mean
>>> at least the filename should be put there (as kind of the first
>>> command line element)?
>>
Roger Pau Monné, on Tue 09 Feb 2016 11:38:43 +0100, wrote:
> Other OSes that use the pv loader don't pass any module at all AFAIK.
GNU Mach does need several modules.
Samuel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-de
flight 38733 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs.
38721
El 9/2/16 a les 11:41, Samuel Thibault ha escrit:
> Roger Pau Monné, on Tue 09 Feb 2016 11:38:43 +0100, wrote:
>> Other OSes that use the pv loader don't pass any module at all AFAIK.
>
> GNU Mach does need several modules.
How do you usually pass multiple modules from an xl configuration file
at
Roger Pau Monné, on Tue 09 Feb 2016 11:45:01 +0100, wrote:
> El 9/2/16 a les 11:41, Samuel Thibault ha escrit:
> > Roger Pau Monné, on Tue 09 Feb 2016 11:38:43 +0100, wrote:
> >> Other OSes that use the pv loader don't pass any module at all AFAIK.
> >
> > GNU Mach does need several modules.
>
>
>>> On 06.02.16 at 05:03, wrote:
> On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> Also - how does this work if you have an older version of SuSE,
>> say SLES10?
>
> Beats me. I just dealt with getting this to compile with what is current.
> I kind of doubt what is in xe
On 09/02/16 08:42, Jan Beulich wrote:
On 08.02.16 at 19:04, wrote:
>> First -- and this isn't a blocker, but just a question (and sorry if
>> it's been answered before) -- why have the "0 means I did it all, > means I did it partially"? Why not just return the number of entries
>> actually h
On 08/02/16 19:03, Roger Pau Monné wrote:
> The format of the boot start info structure is the following (pointed to
> be %ebx):
>
> NOTE: nothing will be loaded at physical address 0, so a 0 value in any of the
> address fields should be treated as not present.
>
> 0 ++
>| mag
El 9/2/16 a les 11:49, Samuel Thibault ha escrit:
> Roger Pau Monné, on Tue 09 Feb 2016 11:45:01 +0100, wrote:
>> El 9/2/16 a les 11:41, Samuel Thibault ha escrit:
>>> Roger Pau Monné, on Tue 09 Feb 2016 11:38:43 +0100, wrote:
Other OSes that use the pv loader don't pass any module at all AFAI
On 09/02/16 10:56, Roger Pau Monné wrote:
> El 9/2/16 a les 11:49, Samuel Thibault ha escrit:
>> Roger Pau Monné, on Tue 09 Feb 2016 11:45:01 +0100, wrote:
>>> El 9/2/16 a les 11:41, Samuel Thibault ha escrit:
Roger Pau Monné, on Tue 09 Feb 2016 11:38:43 +0100, wrote:
> Other OSes that use
Jim Fehlig writes ("Re: [Xen-devel] [RFC] support more qdisk types"):
> I think my previous problem was related to quoting in a disk spec containing
> several ceph monitors. According to $qemu-src/hw/block/rbd.c, ':' is used to
> delimit option=value tuples. I was escaping the colon between a ceph
On Mon, 8 Feb 2016, Corneliu ZUZU wrote:
> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
Why are we doing this? These are not header files, their paths don't
necessarily need to be the same and xen/arch/x86/hvm/hvm.c is ve
On Tue, 2016-02-09 at 10:19 +, Wei Liu wrote:
> On Mon, Feb 08, 2016 at 04:59:46PM -0600, Chong Li wrote:
> >
> > I see. I'll think about re-designing the data structure of
> > libxl_vcpu_sched_params.
> >
>
> Or you can come up with a new API (function) that sets parameter for
> all
> vcpus
On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
> On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
> > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao
> > > wrote:
> > > > From: Shannon Zhao
> > > >
> > > > ACPI 6.0 introduces a new
>>> On 08.02.16 at 17:57, wrote:
> This patch merges almost identical functions hvm_event_int3
> and hvm_event_single_step into a single function called
> hvm_event_software_breakpoint.
Except that "software breakpoint" is rather questionable a name
here, considering that on x86 this is basically
>>> On 08.02.16 at 14:19, wrote:
> @@ -1995,13 +1996,11 @@ static void csched_tick_resume(const struct scheduler
> *ops, unsigned int cpu)
> - now % MICROSECS(prv->tick_period_us) );
> }
>
> -static struct csched_private _csched_priv;
> -
> static const struct scheduler sched_cre
On 2/9/2016 1:03 PM, Stefano Stabellini wrote:
On Mon, 8 Feb 2016, Corneliu ZUZU wrote:
X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
Why are we doing this? These are not header files, their paths don't
necessarily need t
>>> On 09.02.16 at 11:56, wrote:
> On 09/02/16 08:42, Jan Beulich wrote:
> On 08.02.16 at 19:04, wrote:
>>> First -- and this isn't a blocker, but just a question (and sorry if
>>> it's been answered before) -- why have the "0 means I did it all, >> means I did it partially"? Why not just re
I have a virtual machine in which some processes are running. I want to
analysis their behavior using VMI at xen.
My tool has two components:i) xen patch running at hypervisor ii) analyzing
component running at Dom0
1. Xen patch is responsible for collecting the system call information of a
monit
I have a virtual machine in which some processes are running. I want to
analysis their behavior using VMI at xen.
My tool has two components:i) xen patch running at hypervisor ii) analyzing
component running at Dom0
1. Xen patch is responsible for collecting the system call information of a
monit
On 2/9/2016 1:19 PM, Jan Beulich wrote:
On 08.02.16 at 17:57, wrote:
This patch merges almost identical functions hvm_event_int3
and hvm_event_single_step into a single function called
hvm_event_software_breakpoint.
Except that "software breakpoint" is rather questionable a name
here, consider
flight 81285 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 79947
build-amd64
>>> On 09.02.16 at 12:28, wrote:
> On 2/9/2016 1:03 PM, Stefano Stabellini wrote:
>> On Mon, 8 Feb 2016, Corneliu ZUZU wrote:
>>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
>>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
>> Why are we doing this? These are not head
El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
> On 08/02/16 19:03, Roger Pau Monné wrote:
>> The format of the boot start info structure is the following (pointed to
>> be %ebx):
>>
>> NOTE: nothing will be loaded at physical address 0, so a 0 value in any of
>> the
>> address fields should be t
El 8/2/16 a les 22:48, Alex Braunegg ha escrit:
> Hi Ian,
>
> Any update in looking at this issue?
Hello,
I've been able to reproduce this issue and I will prepare a fix. I'm
going to Cc you on the patch if you don't mind, so that you can test it.
Roger.
__
On Thu, 2016-02-04 at 16:50 -0600, Chong Li wrote:
>
> +static int sched_rtds_vcpu_set(libxl__gc *gc, uint32_t domid,
> + const libxl_vcpu_sched_params
> *scinfo)
>
I'd call this sched_rtds_vcpus_params_set().
I know, it's longer, which is bad, but it's a lot more ev
flight 81206 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81206/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 18 leak-check/check fail REGR. vs. 79413
Regressions which are
>>> On 09.02.16 at 05:15, wrote:
> Convert the xenoprof x86 build time option to Kconfig.
First of all it's not clear to me whether this really was ever meant to
be a build time option. It's using := (not ?= ), and without there being
a clear indication that this was intended I'm inclined to assu
flight 81208 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-installfail REGR. vs. 80694
test-amd64
>>> On 09.02.16 at 12:58, wrote:
> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>> On 08/02/16 19:03, Roger Pau Monné wrote:
>>> * PCI Express MMCFG: if Xen is able to identify any of these regions at
>>> boot
>>>time they will also be made available to the guest at the same position
>>>
>>> On 09.02.16 at 12:52, wrote:
> On 2/9/2016 1:19 PM, Jan Beulich wrote:
> On 08.02.16 at 17:57, wrote:
>>> This patch merges almost identical functions hvm_event_int3
>>> and hvm_event_single_step into a single function called
>>> hvm_event_software_breakpoint.
>> Except that "software bre
On 09/02/16 11:48, Jan Beulich wrote:
On 09.02.16 at 11:56, wrote:
>> On 09/02/16 08:42, Jan Beulich wrote:
>> On 08.02.16 at 19:04, wrote:
First -- and this isn't a blocker, but just a question (and sorry if
it's been answered before) -- why have the "0 means I did it all, >>>
On Tue, 9 Feb 2016, Jan Beulich wrote:
> >>> On 09.02.16 at 12:28, wrote:
> > On 2/9/2016 1:03 PM, Stefano Stabellini wrote:
> >> On Mon, 8 Feb 2016, Corneliu ZUZU wrote:
> >>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
> >>> also move arch/arm/hvm.c to arch/arm/hvm/hv
On 2/9/2016 2:12 PM, Jan Beulich wrote:
On 09.02.16 at 12:52, wrote:
On 2/9/2016 1:19 PM, Jan Beulich wrote:
On 08.02.16 at 17:57, wrote:
This patch merges almost identical functions hvm_event_int3
and hvm_event_single_step into a single function called
hvm_event_software_breakpoint.
Except
Hello.
I want to use Mini-OS as Dom0.
What should be done for this purpose?
Someone tried to do something like that? Maybe there are some patches.
With best regards,
Oleksii
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-d
On Tue, 2016-02-09 at 04:27 -0700, Jan Beulich wrote:
> > > > On 08.02.16 at 14:19, wrote:
> > @@ -1995,13 +1996,11 @@ static void csched_tick_resume(const struct
> > scheduler *ops, unsigned int cpu)
> > - now % MICROSECS(prv->tick_period_us) );
> > }
> >
> > -static struct csched
On 2/9/2016 1:55 PM, Jan Beulich wrote:
On 09.02.16 at 12:28, wrote:
On 2/9/2016 1:03 PM, Stefano Stabellini wrote:
On Mon, 8 Feb 2016, Corneliu ZUZU wrote:
X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
Why are we doin
>>> On 09.02.16 at 13:17, wrote:
> On 09/02/16 11:48, Jan Beulich wrote:
> On 09.02.16 at 11:56, wrote:
>>> On 09/02/16 08:42, Jan Beulich wrote:
>>> On 08.02.16 at 19:04, wrote:
> First -- and this isn't a blocker, but just a question (and sorry if
> it's been answered before) -
Hi folks,
GSoc mentor organisation applications are opening and as such we need to get
our project list into shape: the current list of projects are at
http://wiki.xenproject.org/wiki/Xen_Development_Projects and
https://github.com/mirage/mirage-www/wiki/Pioneer-Projects
The application deadli
>>> On 08.02.16 at 18:07, wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -120,6 +120,12 @@ SECTIONS
>.init.data : {
> *(.init.rodata)
> *(.init.rodata.str*)
> +
> + . = ALIGN(32);
Why 32?
> + __setup_start = .;
> + *(.init.setup)
>
flight 81313 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81313/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
version targeted
>>> On 08.02.16 at 18:07, wrote:
> There are only four users, and invbool_param() is an unnecessary cognitive
> overhead to use.
While this isn't necessarily a bad change, I don't agree to either of
these arguments. So I'm going to make my ack here dependent on
seeing some kind of positive feedba
>>> On 08.02.16 at 18:07, wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -121,12 +121,11 @@ void __init cmdline_parse(const char *cmdline)
> simple_strtoll(optval, NULL, 0));
> break;
> case OPT_BOOL:
> -case OPT_I
On Tue, Feb 9, 2016 at 1:53 AM, Ian Campbell
wrote:
> On Mon, 2016-02-08 at 21:48 -0800, Suriyan Ramasami wrote:
> > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> > Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
> > has been used to get all the 8 cores from
El 9/2/16 a les 13:10, Jan Beulich ha escrit:
On 09.02.16 at 12:58, wrote:
>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>>> On 08/02/16 19:03, Roger Pau Monné wrote:
* PCI Express MMCFG: if Xen is able to identify any of these regions at
boot
time they will also be m
flight 81211 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81211/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 80683 pass in 81211
test-amd64-i386-xl-qemuu-ovmf-amd6
>>> On 08.02.16 at 20:03, wrote:
> 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
On 02/08/2016 11:05 PM, Doug Goldstein wrote:
On 2/8/16 10:24 AM, Boris Ostrovsky wrote:
While at it --- I think we should put VPMU code under CONFIG option too,
especially given its support status. I can do that (unless Doug wants to).
I forgot to answer the VPMU part. If you have the band
>>> On 09.02.16 at 14:00, wrote:
> El 9/2/16 a les 13:10, Jan Beulich ha escrit:
> On 09.02.16 at 12:58, wrote:
>>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
On 08/02/16 19:03, Roger Pau Monné wrote:
> * PCI Express MMCFG: if Xen is able to identify any of these regions at
>
flight 81280 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81280/
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.
77834
te
On 09/02/16 12:43, Jan Beulich wrote:
On 08.02.16 at 18:07, wrote:
>> --- a/xen/arch/x86/xen.lds.S
>> +++ b/xen/arch/x86/xen.lds.S
>> @@ -120,6 +120,12 @@ SECTIONS
>>.init.data : {
>> *(.init.rodata)
>> *(.init.rodata.str*)
>> +
>> + . = ALIGN(32);
> Why 32?
>
>> +
On 02/09/2016 05:05 AM, Andrew Cooper wrote:
On 09/02/16 04:15, Doug Goldstein wrote:
diff --git a/xen/include/asm-x86/vpmu.h b/xen/include/asm-x86/vpmu.h
index 67e73dc..4750a1f 100644
--- a/xen/include/asm-x86/vpmu.h
+++ b/xen/include/asm-x86/vpmu.h
@@ -89,10 +89,14 @@ static inline void vpmu_c
On Tue, 2016-02-09 at 04:50 -0800, Suriyan Ramasami wrote:
>
>
> On Tue, Feb 9, 2016 at 1:53 AM, Ian Campbell
> wrote:
> > On Mon, 2016-02-08 at 21:48 -0800, Suriyan Ramasami wrote:
> > > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> > > Code from mcpm-exynos.c and mcpm-pla
scratch_alloc() set scratch_start to the last byte of the current
allocation. The value of scratch_start is then reused as is (if it is
already aligned) in the next allocation. This result in a potential reuse
of the last byte of the previous allocation.
Signed-off-by: Anthony PERARD
---
Chang
>>> On 09.02.16 at 14:52, wrote:
> On 09/02/16 12:43, Jan Beulich wrote:
> On 08.02.16 at 18:07, wrote:
>>> --- a/xen/arch/x86/xen.lds.S
>>> +++ b/xen/arch/x86/xen.lds.S
>>> @@ -120,6 +120,12 @@ SECTIONS
>>>.init.data : {
>>> *(.init.rodata)
>>> *(.init.rodata.str*)
>>> +
On 02/09/2016 06:58 AM, Roger Pau Monné wrote:
El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
On 08/02/16 19:03, Roger Pau Monné wrote:
Description of physical hardware devices will always come from ACPI, in the
absence of any physical hardware device no ACPI tables will be provided. The
pres
> > +# Enable/Disable xsplice support
> > +config XSPLICE
> > + bool "xsplice support"
> > + default y
> > + depends on HAS_XSPLICE
> > + ---help---
> > + Allows a running Xen hypervisor to be patched without rebooting.
> > + This is primarily used to patch an hypervisor with XSA fi
On 09/02/16 14:32, Jan Beulich wrote:
On 09.02.16 at 14:52, wrote:
>> On 09/02/16 12:43, Jan Beulich wrote:
>> On 08.02.16 at 18:07, wrote:
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -120,6 +120,12 @@ SECTIONS
.init.data : {
*(.init.r
On 09/02/16 14:36, Boris Ostrovsky wrote:
> On 02/09/2016 06:58 AM, Roger Pau Monné wrote:
>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>>> On 08/02/16 19:03, Roger Pau Monné wrote:
Description of physical hardware devices will always come from
ACPI, in the
absence of any
flight 81619 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81619/
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 09.02.16 at 15:36, wrote:
> On 02/09/2016 06:58 AM, Roger Pau Monné wrote:
>> El 9/2/16 a les 11:56, Andrew Cooper ha escrit:
>>> On 08/02/16 19:03, Roger Pau Monné wrote:
Description of physical hardware devices will always come from ACPI, in the
absence of any physical hard
>>> On 09.02.16 at 15:40, wrote:
> On 09/02/16 14:32, Jan Beulich wrote:
> On 09.02.16 at 14:52, wrote:
>>> On 09/02/16 12:43, Jan Beulich wrote:
>>> On 08.02.16 at 18:07, wrote:
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -120,6 +120,12 @@ SECTIONS
>>>
On Tue, 2016-02-09 at 09:58 +, Wei Liu wrote:
> On Fri, Feb 05, 2016 at 05:39:39PM -0800, Luis R. Rodriguez wrote:
> > On Thu, Nov 19, 2015 at 3:06 PM, Luis R. Rodriguez
> > wrote:
> > > On Fri, Oct 9, 2015 at 12:34 AM, Jan Beulich
> > > wrote:
> > > > > > > On 08.10.15 at 21:36, wrote:
> >
On 05/02/16 21:22, Tamas K Lengyel wrote:
> The altp2m subsystem in its current form duplicates much of the existing
> code present in p2m for setting mem_access permissions. In this patch we
> consolidate the two versions but keep the separate MEMOP and HVMOP interfaces.
>
> Signed-off-by: Tamas
On 05/02/16 21:22, Tamas K Lengyel wrote:
> Extend the existing get_mem_access memop to allow querying permissions in
> altp2m views as well.
>
> Signed-off-by: Tamas K Lengyel
Reviewed-by: George Dunlap
Sorry for the delay.
___
Xen-devel mailing l
On Tue, 9 Feb 2016, Jan Beulich wrote:
> > In the case of the hardware domain, Xen has traditionally passed-through the
> > native ACPI tables to the guest. This is something that of course we still
> > want to do, but in the case of HVMlite Xen will have to make sure that
> > the data passed in th
On 02/08/2016 02:03 PM, Roger Pau Monné wrote:
The format of the boot start info structure is the following (pointed to
be %ebx):
NOTE: nothing will be loaded at physical address 0, so a 0 value in any of the
address fields should be treated as not present.
0 ++
| magic
On Wed, 2016-02-03 at 16:46 +, Ian Campbell wrote:
> The next Xen technical call is scheduled for:
> Wed 10 Feb 17:00:00 GMT 2016
> `date -d @1455123600`
There are no topics, so the call is cancelled.
___
Xen-devel mailing list
Xen-devel@li
On Fri, 2016-01-29 at 10:16 -0600, Doug Goldstein wrote:
[...]
There were no objections and 3 in favour (plus me) so I've approved you in
the coverity UI.
Thanks for offering to help out ;-)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
On Tue, Feb 09, 2016 at 03:54:05AM -0700, Jan Beulich wrote:
> >>> On 06.02.16 at 05:03, wrote:
> > On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> >> Also - how does this work if you have an older version of SuSE,
> >> say SLES10?
> >
> > Beats me. I just dealt with gett
On Mon, Feb 08, 2016 at 09:58:23AM +, Ian Campbell wrote:
> On Fri, 2016-02-05 at 17:48 -0800, Luis R. Rodriguez wrote:
> > What's up folks? How can this process be made smoother, did I do
> > something wrong, what can I do to help better?
>
> When you first sent this series to Jan + me not co
On Fri, 5 Feb 2016, Ian Campbell wrote:
> On Fri, 2016-02-05 at 20:57 +1100, Steven Haigh wrote:
> >
> > > On thing I was sure on (so didn't write) is whether the second
> > > paragraph
> > > could have an extra sentence:
> > >
> > > If you are using a distro supplied QEMU then the qemu-system-
On Tue, 2016-02-09 at 15:49 +, Stefano Stabellini wrote:
> On Fri, 5 Feb 2016, Ian Campbell wrote:
> > On Fri, 2016-02-05 at 20:57 +1100, Steven Haigh wrote:
> > >
> > > > On thing I was sure on (so didn't write) is whether the second
> > > > paragraph
> > > > could have an extra sentence:
> >
Running QEMU as non-root causes migration and PCI passthrough not to
work properly. Migration can be fixed rather easily
(http://marc.info/?l=xen-devel&m=145382864118600), but PCI passthrough
cannot (http://marc.info/?l=xen-devel&m=145286946113964).
Signed-off-by: Stefano Stabellini
diff --git a
>>> On 09.02.16 at 16:46, wrote:
> On Tue, Feb 09, 2016 at 03:54:05AM -0700, Jan Beulich wrote:
>> >>> On 06.02.16 at 05:03, wrote:
>> > On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> >> Also - how does this work if you have an older version of SuSE,
>> >> say SLES10?
>
On Tue, Feb 09, 2016 at 01:08:13AM -0700, Jan Beulich wrote:
> >>> On 06.02.16 at 02:48, wrote:
> > On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
> > wrote:
> >> From: "Luis R. Rodriguez"
> >>
> >> Here's a slew of build fixes as well as build warning fixes
> >> required when using the late
flight 81339 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81339/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 66399
build-amd64-rumpuserxen
>>> On 09.02.16 at 16:06, wrote:
> On Tue, 9 Feb 2016, Jan Beulich wrote:
>> Will STAO be sufficient for everything that may need customization?
>> I'm particularly worried about processor related methods in DSDT or
>> SSDT, which - if we're really meaning to do as you say - would need
>> to be li
This is most easily explained by the commit log of the first patch:
Xen 4.2 become unsupported upstream in 09/2105 (see
http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
interfaces provided by the toolstack libraries go 4.2 and 4.3 are
indistinguishable.
We assume (and check for in configure) 4.2 or later now. In reality
all of the removed checks are for far older versions.
Signed-off-by: Ian Campbell
---
hw/display/xenfb.c | 7 ---
xen-hvm.c | 14 +-
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/hw/dis
Now that we no longer support Xen 4.2 and earlier only the <470 case
needs this so it can live with all the others.
Signed-off-by: Ian Campbell
---
include/hw/xen/xen_common.h | 34 ++
1 file changed, 14 insertions(+), 20 deletions(-)
diff --git a/include/hw/xen/
The xc version is now always present.
Signed-off-by: Ian Campbell
---
include/hw/xen/xen_common.h | 6 --
xen-hvm.c | 2 +-
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 3a5b537..ec3ca56 100644
Now that 4.2 and earlier are no longer supported "xc_interface *" is
always the right type for the xc interface handle.
Signed-off-by: Ian Campbell
---
hw/xen/xen_backend.c | 4 +--
include/hw/xen/xen_backend.h | 2 +-
include/hw/xen/xen_common.h | 82 +
Xen 4.2 become unsupported upstream in 09/2105 (see
http://wiki.xen.org/wiki/Xen_Release_Features). However as far as the
interfaces provided by the toolstack libraries go 4.2 and 4.3 are
indistinguishable.
Therefore drop support for Xen 4.1 and earlier which removes a whole
pile of compatibility
flight 81366 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81366/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR.
vs. 80121
test-amd64-i386-l
On 09/02/16 16:15, Jan Beulich wrote:
On 09.02.16 at 16:06, wrote:
>> On Tue, 9 Feb 2016, Jan Beulich wrote:
>>> Will STAO be sufficient for everything that may need customization?
>>> I'm particularly worried about processor related methods in DSDT or
>>> SSDT, which - if we're really meanin
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Ian Campbell
CC: Daniel De Graaf
Is this actually an appropraite fix? Software relying on -ENOSYS for Xen
feature detection is going to break when running under an XSM hypervisor.
---
xen/xsm/flask/hooks.c | 1 -
1 file cha
1 - 100 of 157 matches
Mail list logo
