On Tue, Oct 06, 2015 at 07:38:30AM -0600, 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 possibl
On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote:
> 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_*
flight 62665 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62665/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 62389
REGR. vs. 60727
Tes
On 06/10/15 14:51, Ian Campbell wrote:
> On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote:
>> Having in hand the index for the rank is very handy to avoid computing
>> it everytime.
>
> "every time".
>
>> For now, use it when enabling/disabling the vIRQs rather than a formula
>> which is not
On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote:
> 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 gi
On Tue, 6 Oct 2015, Roger Pau Monné wrote:
> Do KVM guests also need such extensive set of modifications in order to
> run using 64KB pages? I know it's not fair to compare KVM and Xen in
> this regard, because the interfaces are very different, but that's what
> developers are going to look at.
Q
On 06/10/15 14:47, Ian Campbell wrote:
> On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote:
>> [...]
>> +/*
>> + * Sign extend if required.
>> + * Note that we expect the read handler to have zeroed the bit
>> + * unused in the register.
>
> You were (correctly) going to change
On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote:
> Having in hand the index for the rank is very handy to avoid computing
> it everytime.
"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
On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote:
> 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
On Mon, 2015-10-05 at 13:51 +0100, Julien Grall wrote:
> [...]
> +/*
> + * Sign extend if required.
> + * Note that we expect the read handler to have zeroed the bit
> + * unused in the register.
You were (correctly) going to change this to
Note that we expect the read handler
On Mon, 2015-10-05 at 13:58 +0100, Julien Grall wrote:
> On 05/10/15 13:51, Julien Grall wrote:
> > 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 mani
On Mon, 2015-10-05 at 18:09 +0100, Julien Grall wrote:
> Hi,
>
> On 05/10/15 17:38, Brijesh Singh wrote:
> > As per PSCI 0.2 spec, if CPU_ON entry_point_address is 64-bit then SMC
> > call function ID parameter should be set to SMC64 version.
> >
> > Signed-off-by: Brijesh Singh
>
> Reviewed-by
On Tue, 2015-10-06 at 13:50 +0100, George Dunlap wrote:
> On 03/10/15 02:58, Dario Faggioli wrote:
> > Signed-off-by: Dario Faggioli
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -287,6 +287,7 @@ F: xen/common/sched_rt.c
> >
> > SCHEDULING
> > M: George Dunlap
> > +M: Dario Faggiol
On Tue, 2015-10-06 at 12:39 +0100, Wei Liu wrote:
> And for the record, if my google-fu doesn't fail me, it's possible to
> load shared library into python interpreter using "dl" module in 2.7 and
> "ctypes" module in 3.x.
Possible, but not especially convenient since you need to convert the C
pr
>>> 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 releases.
I find it kind of odd to try to answer question 2 (c
The kernel dist built by ts-kernel-build puts the corresponding dtbs
into /boot/dtbs/$kvers.
The host installer's dtbs remain in /boot/dtbs and are used when
booting the native kernel.
It's possible that this change will expose bugs which exist in the
DTBs in previous kernel branches (3.18 and 4.
By switching <<'END' to <
Acked-by: Ian Jackson
---
v2: Call a backslash a backslash.
---
Osstest/Debian.pm | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 9347c49..d56e410 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debi
And to Osstest::%arch_debian2*.
Untested (but hopefully pretty obvious).
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
Note that this replaces a hunk in "Add arm64 build and test jobs"
---
Osstest.pm | 6 --
ts-kernel-build | 1 +
2 files changed, 5 insertions(+), 2 deletions
Modelled after %arch_debian2xen.
Will be used in ts-kernel-build.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
v2: Wrapped long line
---
Osstest.pm | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index fc8334d..cbef3ff 100644
---
This is always either "foo_defconfig" or "defconfig". Record only
"foo" or undef and construct the name.
This makes the $archparams less verbose.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
ts-kernel-build | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a
Which contains the relevant details from %archparms, making the use
sites simpler.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
ts-kernel-build | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ts-kernel-build b/ts-kernel-build
index f26eba8..3006eeb 100755
--- a
This is always arch/$karch/boot/$img. Store $img in %archparms and use
%arch_debian2linux to construct the full path as needed.
This makes the $archparams less verbose.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
ts-kernel-build | 10 ++
1 file changed, 6 insertions(+), 4 del
These are installed to $(INSTALL_PATH)/dtbs/$(KERNEL_RELEASE) where
$(INSTALL_PATH) defaults to /boot but we override it to our staging
/boot.
Note that ts-host-install will install the OS dtbs directly into
/boot/dtbs without the subdirectory, so this won't clash and could be
considered a fallbac
Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST 6/8] ts-kernel-build:
Include dtbs in dist file"):
> I went with:
>
> + make $makeflags \\
> + INSTALL_PATH=$builddir/dist/boot \\
> + INSTALL_MOD_PATH=$builddir/dist \\
> + modules_install $dtbs_
On ARM we have been booting using the DTBS provided by the host Debian
kernel package (i.e. the ones from 3.16) even when we are booting a
Xen+kernel which we have built ourselves.
Recent Linux kernels (at least linux-next and linux-linus, perhaps mingo
-tip too) have changes which are incompatibl
Ian Campbell writes ("Re: [PATCH OSSTEST 6/8] ts-kernel-build: Include dtbs in
dist file"):
> On Mon, 2015-10-05 at 17:22 +0100, Ian Jackson wrote:
> > `modules_install' on the next line, to avoid hiding it in
> > INSTALL_BLAH=.
>
> I did it that way because INSTALL_MOD_PATH is the variable which
Ian Campbell writes ("Re: [PATCH OSSTEST 5/8] ts-kernel-build: Add arm64
support"):
> On Mon, 2015-10-05 at 17:20 +0100, Ian Jackson wrote:
> > IWBN to double-check that the generated filename is correct before we
> > try to push this.
>
> For arm64 specifically or for all arches?
Just for arm64
On Tue, 2015-10-06 at 14:13 +0100, Stefano Stabellini wrote:
> On Mon, 5 Oct 2015, Ian Campbell wrote:
> > On Mon, 2015-10-05 at 16:53 +0100, Stefano Stabellini wrote:
> > > > Wasn't there some code to plumb this into xl at one point? Did that
> > > > get
> > > > dropped along the way?
> > >
> > >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.3b-rc4-tag
xen: bug fixes for 4.3-rc4
- - Fix VM save performance regression with x86 PV guests.
- - Make kexec work in x86 PVHVM gues
On Mon, 2015-10-05 at 17:29 +0100, Ian Campbell wrote:
> On Mon, 2015-10-05 at 17:22 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST 6/8] ts-kernel-build: Include dtbs
> > in dist file"):
> > > These are installed to $(INSTALL_PATH)/dtbs/$(KERNEL_RELEASE) where
> > > $(INSTALL_PA
On Tue, 2015-10-06 at 14:06 +0100, Andrew Cooper wrote:
> On 06/10/15 13:58, Wei Liu wrote:
> > On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
> > > On 06/10/15 12:35, Juergen Gross wrote:
> > > > In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is
> > > > currently
> > >
On Mon, 5 Oct 2015, Ian Campbell wrote:
> On Mon, 2015-10-05 at 16:53 +0100, Stefano Stabellini wrote:
> > > Wasn't there some code to plumb this into xl at one point? Did that get
> > > dropped along the way?
> >
> > device_model_user is added to the idl by this patch, I think that is
> > enough,
On Tue, Oct 06, 2015 at 12:07:58PM +0100, Wei Liu wrote:
> Hi all
>
> 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 releases.
>
> I start this
On Tue, Oct 06, 2015 at 07:03:28AM -0600, Jan Beulich wrote:
> >>> On 05.10.15 at 18:22, wrote:
> > FWIW current scheme (last 3 releases as stable releases) means a release
> > is supported for at least 27 months (well, let's forget about the
> > possibility of releasing a version earlier than exp
On Tue, 2015-10-06 at 12:07 +0100, Wei Liu wrote:
> 2. What to do with the non-LTS releases?
>
> I think they should still be considered stable releases for some
> time. I'm just not sure for how long they should receive updates. One
> way of looking at them is to use the same concept as Linux --
All the QEMU side XSA-131 patches are already in the qemu-xen 4.3, 4.4
and 4.5 trees.
On Tue, 6 Oct 2015, Ian Campbell wrote:
> Ian, Can you backport this to 4.5 and earlier please.
>
> On Fri, 2015-07-03 at 15:49 +0100, Ian Campbell wrote:
> > On Tue, 2015-06-02 at 16:47 +0100, Ian Campbell wrot
On 06/10/15 13:58, Wei Liu wrote:
> On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
>> On 06/10/15 12:35, Juergen Gross wrote:
>>> In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
>>> being used by an in-tree component (qemu-xen). All other functions are
>>> su
On Mon, 2015-10-05 at 17:03 -0500, Doug Goldstein wrote:
> 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 on
On Tue, 6 Oct 2015, Jan Beulich wrote:
> > In fact some of the feedback from the survey suggests that the
> > disagreements
> > that are highlighted after some time has passed cause the most grievances.
>
> I'm not sure I understand: How is late disagreement any worse
> than immediate one?
It
>>> On 05.10.15 at 18:22, wrote:
> FWIW current scheme (last 3 releases as stable releases) means a release
> is supported for at least 27 months (well, let's forget about the
> possibility of releasing a version earlier than expected for now because
> it never happened before).
Where did you fin
On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
+### xSplice interdependencies
+
+xSplice patches interdependencies are tricky.
+
+There are the ways this can be addressed:
+ * A single large patch that subsumes and replaces all previous ones.
+ Over the life-time of patching the hyperviso
On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
> On 06/10/15 12:35, Juergen Gross wrote:
> > In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
> > being used by an in-tree component (qemu-xen). All other functions are
> > superfluous wrappers of the domain buil
On 06/10/15 12:07, Wei Liu wrote:
> Hi all
>
> 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 releases.
>
> I start this thread hoping it's clea
>>> On 06.10.15 at 00:03, wrote:
> Wire in the Kconfig build and makefile rules to be able to generate
> valid configuration files to be used by the build process.
>
> Signed-off-by: Doug Goldstein
> ---
> .gitignore| 8
> xen/Kconfig | 26 +++
On 06/10/15 12:35, Juergen Gross wrote:
> In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
> being used by an in-tree component (qemu-xen). All other functions are
> superfluous wrappers of the domain builder which can be removed.
>
> Suggested-by: Ian Campbell
> Signed-off-
On 03/10/15 02:58, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli
> ---
> Cc: George Dunlap
> ---
> MAINTAINERS |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f008a8c..b612e06 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -287,6 +287,7
mg-debian-installer-update-all has been run on the production instance
and TftpDiVersion is also updated to match.
The resulting binaries have also been copied to the Cambridge
instance, so update Cambridge config too.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
---
Osstest.pm
This is "Sync mode. Don't return until the partitions are created",
which seems to be needed in Jessie. The option also exists in Wheezy,
according to the manpage.
Without this the following mount fails having apparently raced against
the creation of the device nodes.
Signed-off-by: Ian Campbell
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
---
Osstest/TestSupport.pm | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index d8c5762..69da459 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -63,7
This has the effect of switching $gho->{Lvdev} from /dev/$VG/$LV to
/dev/mapper/$VG-$LV (where $VG and $LV have an s/-/--/ transformation
applied).
The two paths point to the samedevice and most call sites don't care
about the distinction. Some places which use "kpartx $dev" to Lvdev
expect to be
The x86 and arm kernels are inconsistently named upstream, and then
renamed in mg-debian-installer-update as:
== KERNEL == INITRD ==
Debian Osstest Debian Osstest
------
prepareguest has already assigned this so we should use it instead of
replicating (perhaps wrongly since target_guest_lv_name and
target_choose_vg can behave differently if multiple vgs are present).
$gho->{Lvdev} has been adjusted to return /dev/mapper/vg-lv paths
which is required to be able to
root is not a "guest lv", so using target_guest_lv_name is misleading.
target_guest_lv_name also fails to properly handle the d-i vg name
correctly, which di_vg_name does. Specifically under Jessie an extra
"-vg" is appended to the hostname compared with Wheezy and Squeeze.
Signed-off-by: Ian Cam
This is not enabled in the arm defconfig (it is in x86) and without it
a Debian Jessie userspace with systemd fails to boot with:
systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file or directory
While we arrange to use sysvinit in the host and in d-i installed
guests we do not do so
Compared with last time there are a few new patches to fix things I noticed
while testing and the prerequisites for actually deploying (f/w fix on
arndale and git cache) are now addressed. It remains the case that the
first 7 patches are OK to go in now and the final one to do the switch
should per
>>> On 06.10.15 at 00:03, wrote:
> Brings in the Kbuild/Kconfig plumbing from the Linux 4.2 release.
>
> Signed-off-by: Doug Goldstein
> ---
> xen/Makefile.linux | 1596 +++
> xen/include/linux/kconfig.h| 54 +
> xen/scripts/Kbuild.i
On Tue, Oct 06, 2015 at 02:25:39PM +0200, Sander Eikelenboom wrote:
> On 2015-10-06 13:52, Konrad Rzeszutek Wilk wrote:
> >On October 6, 2015 7:26:35 AM EDT, Wei Liu wrote:
> >>On Tue, Oct 06, 2015 at 01:19:17PM +0200, Sander Eikelenboom wrote:
> >>>Hi,
> >>>
> >>>Today i tried building installing
On Tue, 2015-10-06 at 06:25 -0600, Jan Beulich wrote:
> > > > On 06.10.15 at 12:26, wrote:
> > Now arguably any maintainer of a piece of libxl ought to be familiar with
> > all of that. But, personally I don't think that is very reasonable either
> > as a burden for those feature maintainers or pa
>>> On 06.10.15 at 00:03, wrote:
Changes like this should be explained:
> Signed-off-by: Doug Goldstein
> ---
> xen/scripts/basic/.gitignore | 1 -
> xen/scripts/basic/Makefile | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/xen/scripts/basic/.gitignore b/xen/scripts/basic/.gitign
>>> On 06.10.15 at 11:47, wrote:
> On 05/10/15 23:03, Doug Goldstein wrote:
>> Use the Kconfig generated HAS_PASSTHROUGH defines for the code base.
>>
>> Signed-off-by: Doug Goldstein
>>
>
> Moving to a Kconfig style of selecting features changes the meaning of
> our HAS_ prefix.
>
> IMO, the H
>>> On 06.10.15 at 11:58, wrote:
> On 05/10/15 23:03, Doug Goldstein wrote:
>> new file mode 100644
>> index 000..e69de29
>> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
>> new file mode 100644
>> index 000..5e34f4e
>> --- /dev/null
>> +++ b/xen/arch/x86/Kconfig
>> @@ -0,0 +1,2
On October 6, 2015 8:25:39 AM EDT, Sander Eikelenboom
wrote:
>On 2015-10-06 13:52, Konrad Rzeszutek Wilk wrote:
>> On October 6, 2015 7:26:35 AM EDT, Wei Liu
>wrote:
>>> On Tue, Oct 06, 2015 at 01:19:17PM +0200, Sander Eikelenboom wrote:
Hi,
Today i tried building installing a fr
On 2015-10-06 13:52, Konrad Rzeszutek Wilk wrote:
On October 6, 2015 7:26:35 AM EDT, Wei Liu wrote:
On Tue, Oct 06, 2015 at 01:19:17PM +0200, Sander Eikelenboom wrote:
Hi,
Today i tried building installing a fresh clone of Xen 4.6.0 (to be)
on a
minimal Debian Jessie install.
The package li
>>> On 06.10.15 at 12:26, wrote:
> Now arguably any maintainer of a piece of libxl ought to be familiar with
> all of that. But, personally I don't think that is very reasonable either
> as a burden for those feature maintainers or particularly as a strategy for
> ensuring the library remains cohe
>>> On 06.10.15 at 00:31, wrote:
>> On 5 Oct 2015, at 15:32, Jan Beulich wrote:
>> Of course
>> that doesn't rule out the wider scope maintainer requesting
>> changes despite the other's ack, but that's symmetrical: For a
>> change to go in, no maintainer should disagree (and in fact
>> reasonabl
>>> On 06.10.15 at 11:36, wrote:
> On Tue, 2015-10-06 at 10:19 +0100, George Dunlap wrote:
>> On Mon, Oct 5, 2015 at 11:31 PM, Lars Kurth
>> > I also think that for some areas of code (e.g. if experimental and
>> > sufficiently modular) a more relaxed approach may well be acceptable
>> > until it
On October 6, 2015 7:26:35 AM EDT, Wei Liu wrote:
>On Tue, Oct 06, 2015 at 01:19:17PM +0200, Sander Eikelenboom wrote:
>> Hi,
>>
>> Today i tried building installing a fresh clone of Xen 4.6.0 (to be)
>on a
>> minimal Debian Jessie install.
>> The package list in the README seems to be missing "l
On Tue, Oct 06, 2015 at 01:33:54PM +0200, Juergen Gross wrote:
> On 10/06/2015 01:18 PM, Wei Liu wrote:
> >On Tue, Oct 06, 2015 at 12:46:08PM +0200, Juergen Gross wrote:
> >>Remove lots of functions in tools/python/xen/lowlevel/xc/xc.c as they
> >>are not used anywhere in the tree. In fact only one
In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
being used by an in-tree component (qemu-xen). All other functions are
superfluous wrappers of the domain builder which can be removed.
Suggested-by: Ian Campbell
Signed-off-by: Juergen Gross
---
tools/libxc/include/xengues
On 10/06/2015 01:18 PM, Wei Liu wrote:
On Tue, Oct 06, 2015 at 12:46:08PM +0200, Juergen Gross wrote:
Remove lots of functions in tools/python/xen/lowlevel/xc/xc.c as they
are not used anywhere in the tree. In fact only one function is still
being used from pygrub, namely "xeninfo". All other us
On Tue, Oct 06, 2015 at 01:19:17PM +0200, Sander Eikelenboom wrote:
> Hi,
>
> Today i tried building installing a fresh clone of Xen 4.6.0 (to be) on a
> minimal Debian Jessie install.
> The package list in the README seems to be missing "libc6-dev-i386" which
> seems to be needed for a default bu
Hi,
Today i tried building installing a fresh clone of Xen 4.6.0 (to be) on
a minimal Debian Jessie install.
The package list in the README seems to be missing "libc6-dev-i386"
which seems to be needed for a default build (.configure && make && make
install) which also builds 32-bit pieces.
On Tue, Oct 06, 2015 at 12:46:08PM +0200, Juergen Gross wrote:
> Remove lots of functions in tools/python/xen/lowlevel/xc/xc.c as they
> are not used anywhere in the tree. In fact only one function is still
> being used from pygrub, namely "xeninfo". All other users seem to have
> gone with nuking
Hi all
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 releases.
I start this thread hoping it's clearer that downstream consumers like
distributions
On Tue, 2015-10-06 at 12:56 +0200, Juergen Gross wrote:
> On 10/06/2015 10:56 AM, Ian Campbell wrote:
> > On Tue, 2015-10-06 at 08:33 +0200, Juergen Gross wrote:
> > > Do we have any requirements to be compatible to old releases
> > > regarding
> > > the functions in tools/python/xen/lowlevel/xc/xc
On 05/10/15 10:34, Andrew Cooper wrote:
> On 02/10/15 16:48, Roger Pau Monne wrote:
>> Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or
>> disabling specific devices emulated inside of Xen for HVM guests.
>>
>> Signed-off-by: Roger Pau Monné
>> Acked-by: Wei Liu
>> Cc: Ian
On 10/06/2015 10:56 AM, Ian Campbell wrote:
On Tue, 2015-10-06 at 08:33 +0200, Juergen Gross wrote:
Do we have any requirements to be compatible to old releases regarding
the functions in tools/python/xen/lowlevel/xc/xc.c ?
IMHO, no.
There are also too many compatibility shims in front of the
On Tue, 2015-10-06 at 04:21 +, osstest service owner wrote:
> flight 62651 linux-3.18 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62651/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-qemut-
flight 62663 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62663/
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
Remove lots of functions in tools/python/xen/lowlevel/xc/xc.c as they
are not used anywhere in the tree. In fact only one function is still
being used from pygrub, namely "xeninfo". All other users seem to have
gone with nuking xm/xend.
Signed-off-by: Juergen Gross
---
tools/python/xen/lowlevel/
On Mon, 2015-10-05 at 08:32 -0600, Jan Beulich wrote:
> > ! It appears to me that the idea of nested ownership, would maybe be clearer
> > ! and better set expectations. It is also consistent with the expectation
> > ! of "meritocracy". This may in turn may better set expectations
> > ! for contri
On Tue, 2015-10-06 at 10:56 +0100, George Dunlap wrote:
> On Mon, Oct 5, 2015 at 11:25 PM, Julien Grall
> wrote:
> > Hi,
> >
> > On 05/10/2015 23:03, Doug Goldstein wrote:
> > >
> > > Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base.
> >
> >
> > If you are going to rename al
On 06/10/15 11:15, Julien Grall wrote:
> Hi Doug,
>
> On 05/10/2015 23:03, Doug Goldstein wrote:
>> 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 t
On Tue, 2015-10-06 at 11:28 +0200, Roger Pau Monné wrote:
> El 22/09/15 a les 12.59, Ian Campbell ha escrit:
> > On Mon, 2015-09-14 at 17:23 +0200, Roger Pau Monné wrote:
> > > I'm not saying that we shouldn't take those patches, I'm just saying
> > > that IMHO this is a workaround, and I would lik
Hi Doug,
On 05/10/2015 23:03, Doug Goldstein wrote:
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 loc
El 06/10/15 a les 11.58, Julien Grall ha escrit:
> Hi Roger,
>
> On 06/10/2015 10:39, Roger Pau Monné wrote:
>> El 05/10/15 a les 19.05, Julien Grall ha escrit:
>>> On 05/10/15 17:01, Roger Pau Monné wrote:
El 11/09/15 a les 21.32, Julien Grall ha escrit:
> ring_req->u.rw.nr_seg
On 06/10/15 11:02, Julien Grall wrote:
>
>
> On 06/10/2015 10:56, George Dunlap wrote:
>> On Mon, Oct 5, 2015 at 11:25 PM, Julien Grall
>> wrote:
>>> Hi,
>>>
>>> On 05/10/2015 23:03, Doug Goldstein wrote:
Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base.
>>>
>>>
>>>
On Tue, 2015-10-06 at 10:34 +0100, Andrew Cooper wrote:
> On 06/10/15 10:32, Andrew Cooper wrote:
> > On 06/10/15 10:11, Roger Pau Monné wrote:
> > > El 06/10/15 a les 10.56, Ian Campbell ha escrit:
> > > > On Tue, 2015-10-06 at 08:33 +0200, Juergen Gross wrote:
> > > > > Do we have any requirement
On 06/10/2015 10:56, George Dunlap wrote:
On Mon, Oct 5, 2015 at 11:25 PM, Julien Grall wrote:
Hi,
On 05/10/2015 23:03, Doug Goldstein wrote:
Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base.
If you are going to rename all HAS_* to CONFIG_HAS_, please drop the HAS
whi
Hi Roger,
On 06/10/2015 10:39, Roger Pau Monné wrote:
El 05/10/15 a les 19.05, Julien Grall ha escrit:
On 05/10/15 17:01, Roger Pau Monné wrote:
El 11/09/15 a les 21.32, Julien Grall ha escrit:
ring_req->u.rw.nr_segments = num_grant;
+ if (unlikely(require_extra_
On 05/10/15 23:03, Doug Goldstein wrote:
> new file mode 100644
> index 000..e69de29
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> new file mode 100644
> index 000..5e34f4e
> --- /dev/null
> +++ b/xen/arch/x86/Kconfig
> @@ -0,0 +1,28 @@
> +# Select 32 or 64 bit
> +config 64BI
On Mon, Oct 5, 2015 at 11:25 PM, Julien Grall wrote:
> Hi,
>
> On 05/10/2015 23:03, Doug Goldstein wrote:
>>
>> Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base.
>
>
> If you are going to rename all HAS_* to CONFIG_HAS_, please drop the HAS
> which is now redundant.
>
>>
>> Sign
On 05/10/15 23:03, Doug Goldstein wrote:
> Use the Kconfig generated HAS_PASSTHROUGH defines for the code base.
>
> Signed-off-by: Doug Goldstein
>
Moving to a Kconfig style of selecting features changes the meaning of
our HAS_ prefix.
IMO, the HAS_ should disappear in the conversion, as the CON
On 05/10/2015 14:40, Wei Liu wrote:
On Sun, Oct 04, 2015 at 08:24:02PM +0100, Julien Grall wrote:
The keyword typeof is not portable:
/usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
of function 'typeof' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
Signe
On 06/10/15 10:39, Andrew Cooper wrote:
> On 05/10/15 23:03, Doug Goldstein wrote:
>> This is very incomplete and is only posted in hopes of getting some feedback
>> if this conversion is welcome by the community. There are a few different
>> ways I can go from here.
>>
>> * convert all of include/
El 05/10/15 a les 19.05, Julien Grall ha escrit:
> On 05/10/15 17:01, Roger Pau Monné wrote:
>> El 11/09/15 a les 21.32, Julien Grall ha escrit:
>>> The minimal size of request in the block framework is always PAGE_SIZE.
>>> It means that when 64KB guest is support, the request will at least be
>>>
On 05/10/15 23:03, Doug Goldstein wrote:
> This is very incomplete and is only posted in hopes of getting some feedback
> if this conversion is welcome by the community. There are a few different
> ways I can go from here.
>
> * convert all of include/$(ARCH)/config.h
> * move this to the top level
This run is configured for baseline tests only.
flight 38127 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38127/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-vhd 20 guest-start/debia
On Tue, 2015-10-06 at 10:19 +0100, George Dunlap wrote:
> On Mon, Oct 5, 2015 at 11:31 PM, Lars Kurth
> > I also think that for some areas of code (e.g. if experimental and
> > sufficiently modular) a more relaxed approach may well be acceptable
> > until it is more widely adopted. Maybe we can al
On 06/10/15 10:32, Andrew Cooper wrote:
> On 06/10/15 10:11, Roger Pau Monné wrote:
>> El 06/10/15 a les 10.56, Ian Campbell ha escrit:
>>> On Tue, 2015-10-06 at 08:33 +0200, Juergen Gross wrote:
Do we have any requirements to be compatible to old releases regarding
the functions in tools
101 - 200 of 222 matches
Mail list logo
