On Tue, Jan 12, 2016 at 05:56:16PM +0100, Vitaly Kuznetsov wrote:
> Currently, all newly added memory blocks remain in 'offline' state unless
> someone onlines them, some linux distributions carry special udev rules
> like:
>
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
> ATTR{sta
On Tue, Jan 12, 2016 at 05:38:32PM +, David Vrabel wrote:
> On 12/01/16 16:56, Vitaly Kuznetsov wrote:
> > Add support for the newly added kernel memory auto onlining policy to Xen
> > ballon driver.
> [...]
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -37,23 +37,29 @@ con
On Tue, 2016-01-12 at 14:56 +, David Vrabel wrote:
> On 11/01/16 23:01, Stephen Rothwell wrote:
> > Hi David,
> >
> > On Mon, 11 Jan 2016 11:32:01 + David Vrabel wrote:
> > >
> > > Please git pull the following tag:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
flight 77902 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77902/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
El 13/01/16 a les 4.19, Doug Goldstein ha escrit:
> On 1/12/16 7:14 AM, Roger Pau Monne wrote:
>> According to the FreeBSD sysconf man page [0] if the variable is associated
>> with functionality that is not supported, -1 is returned and errno is not
>> modified. Modify libxl__dm_runas_helper so it
This run is configured for baseline tests only.
flight 38626 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38626/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 d
On Wed, 13 Jan 2016, Juergen Gross wrote:
> On 12/01/16 18:23, Stefano Stabellini wrote:
> > On Tue, 12 Jan 2016, Juergen Gross wrote:
> >> On 12/01/16 18:05, Stefano Stabellini wrote:
> >>> On Tue, 12 Jan 2016, Jan Beulich wrote:
> >>> On 12.01.16 at 13:07, wrote:
> > On Mon, 11 Jan 2016,
On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:
> >The issue I have with the SYNC description in the text above is that it
> >describes the single CPU (program order) and the dual-CPU (confusingly
> >named global order) cases, but then doesn't generalise any further. That
> >means
With xen/Makefile including include/config/auto.conf.cmd, environment
variables checked in the latter must be available at the time of
inclusion of that file, and hence must be populated in xen/Makefile
rather than by passing to or inside xen/tools/kconfig/Makefile.kconfig.
Otherwise incremental re
Il 11/01/2016 16:00, Wei Liu ha scritto:
On Tue, Dec 01, 2015 at 05:04:35PM +0100, Fabio Fantoni wrote:
This patch adds basic spice support for pv domUs.
The qemu parameters are the same as the hvm ones and they works.
Therefore xl cfg parameters are the same as the hvm ones except that
features
>>> On 12.01.16 at 18:49, wrote:
> El 12/01/16 a les 17.31, Jan Beulich ha escrit:
> On 12.01.16 at 17:12, wrote:
>>> @@ -2087,19 +2100,21 @@ static int hvm_load_cpu_ctxt(struct domain *d,
>>> hvm_domain_context_t *h)
>>> seg.attr.bytes = ctxt.ldtr_arbytes;
>>> hvm_set_segment_regi
David Vrabel writes:
> On 12/01/16 16:56, Vitaly Kuznetsov wrote:
>> Add support for the newly added kernel memory auto onlining policy to Xen
>> ballon driver.
> [...]
>> --- a/drivers/xen/Kconfig
>> +++ b/drivers/xen/Kconfig
>> @@ -37,23 +37,29 @@ config XEN_BALLOON_MEMORY_HOTPLUG
>>
>>
On 13/01/16 07:30, Jan Beulich wrote:
> This simplifies a number of pointless conditionals: Bits 0 and 1 of
> xcomp_bv don't matter anyway, and as long as none of bits 2..62 are
> set, setting bit 63 is pointless too unless XSAVES is in use.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Coop
David Rientjes writes:
> On Tue, 12 Jan 2016, Vitaly Kuznetsov wrote:
>
>> diff --git a/Documentation/memory-hotplug.txt
>> b/Documentation/memory-hotplug.txt
>> index ce2cfcf..ceaf40c 100644
>> --- a/Documentation/memory-hotplug.txt
>> +++ b/Documentation/memory-hotplug.txt
>> @@ -254,12 +254,2
>>> On 13.01.16 at 07:12, wrote:
>> From: Xu, Quan
>> Sent: Thursday, January 07, 2016 9:47 PM
>>
>> > On January 07, 2016 9:28 PM, wrote:
>> > >>> On 07.01.16 at 02:39, wrote:
>> > > On January 06, 2016 7:26 PM, wrote:
>> > >> > I didn't think about the full logic thoroughly now. But it woul
On Wed, 6 Jan 2016, Leo wrote:
> Public bug reported:
>
> I'm using Arch Linux, with all needed libs packages installed via ABS
> (compiled from source).
> I tried to clone the master repository, the v2.5.0 and the stable-2.4.0, all
> I had the same problems:
Hello Leo,
what is the version of X
On 13/01/16 11:41, Stefano Stabellini wrote:
> On Wed, 13 Jan 2016, Juergen Gross wrote:
>> On 12/01/16 18:23, Stefano Stabellini wrote:
>>> On Tue, 12 Jan 2016, Juergen Gross wrote:
On 12/01/16 18:05, Stefano Stabellini wrote:
> On Tue, 12 Jan 2016, Jan Beulich wrote:
> On 12.01.1
On Wed, 13 Jan 2016, Juergen Gross wrote:
> On 13/01/16 11:41, Stefano Stabellini wrote:
> > On Wed, 13 Jan 2016, Juergen Gross wrote:
> >> On 12/01/16 18:23, Stefano Stabellini wrote:
> >>> On Tue, 12 Jan 2016, Juergen Gross wrote:
> On 12/01/16 18:05, Stefano Stabellini wrote:
> > On Tue
flight 77939 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
On 13/01/16 12:26, Stefano Stabellini wrote:
> On Wed, 13 Jan 2016, Juergen Gross wrote:
>> On 13/01/16 11:41, Stefano Stabellini wrote:
>>> On Wed, 13 Jan 2016, Juergen Gross wrote:
On 12/01/16 18:23, Stefano Stabellini wrote:
> On Tue, 12 Jan 2016, Juergen Gross wrote:
>> On 12/01/16
On 12/01/16 12:07, Stefano Stabellini wrote:
> On Mon, 11 Jan 2016, David Vrabel wrote:
>> On 11/01/16 17:17, Andrew Cooper wrote:
>>> So from one point of view, sufficient justification for this change is
>>> "because the Linux way isn't the only valid way to do this".
>>
>> "Because we can" isn't
flight 77930 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
62112
Reg
The HVMlite series removed the initialization of the emulated PIT for PV
guests, but the handler was still reachable, which means a PV guests can
crash Xen if it pokes at IO ports 0x42, 0x43 or 0x61. Completely remove the
PV PIT handler and move the PIT initialization to HVM guests only.
Signed-of
The BSP will be marked as initialised after hvm_load_cpu_ctxt has loaded the
initial state, which is called from the toolstack during domain creation.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 4
1 file changed, 4 deletions(-)
diff
Hello,
This series contains some bug fixes for HVMlite DomU and some preparatory
patches for HVMlite Dom0 support.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Current implementation of elf_load_bsdsyms is broken when loading inside of
a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
memory space, which it is not.
Take the oportunity to do some cleanup and properly document how
elf_{parse/load}_bsdsyms works. The new implementa
And introduce UNSET_ADDR32.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
tools/libxc/xc_dom_elfloader.c | 2 +-
xen/common/libelf/libelf-dominfo.c | 1 +
xen/include/xen/libelf.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff
Only intercept accesses to IO port 0xcf8 if there's at least one IOREQ
server, otherwise it makes no sense since the only code that uses the value
stored by hvm_access_cf8 is the IOREQ server.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 8 +
>>> On 13.01.16 at 13:32, wrote:
Re the title: I think the fix here really is to the checking against the
right value, not the initialization?
> tools/libxc/xc_dom_elfloader.c | 2 +-
> xen/common/libelf/libelf-dominfo.c | 1 +
> xen/include/xen/libelf.h | 1 +
> 3 files changed,
El 13/01/16 a les 13.46, Jan Beulich ha escrit:
On 13.01.16 at 13:32, wrote:
>
> Re the title: I think the fix here really is to the checking against the
> right value, not the initialization?
Yes, the initialization doesn't matter much, the proper fix is the
checking. I would change it to:
On Wed, 13 Jan 2016, David Vrabel wrote:
> On 12/01/16 12:07, Stefano Stabellini wrote:
> > On Mon, 11 Jan 2016, David Vrabel wrote:
> >> On 11/01/16 17:17, Andrew Cooper wrote:
> >>> So from one point of view, sufficient justification for this change is
> >>> "because the Linux way isn't the only
flight 77919 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77919/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 9 debian-install fail like 77846
Tests which did not succeed,
This run is configured for baseline tests only.
flight 38627 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38627/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 capture-logs
>>> On 13.01.16 at 13:52, wrote:
> El 13/01/16 a les 13.46, Jan Beulich ha escrit:
> On 13.01.16 at 13:32, wrote:
>>
>> Re the title: I think the fix here really is to the checking against the
>> right value, not the initialization?
>
> Yes, the initialization doesn't matter much, the prope
On 13/01/16 13:02, Jan Beulich wrote:
On 13.01.16 at 13:52, wrote:
>> El 13/01/16 a les 13.46, Jan Beulich ha escrit:
>> On 13.01.16 at 13:32, wrote:
>>> Re the title: I think the fix here really is to the checking against the
>>> right value, not the initialization?
>> Yes, the initiali
>>> On 13.01.16 at 14:05, wrote:
> On 13/01/16 13:02, Jan Beulich wrote:
> On 13.01.16 at 13:52, wrote:
>>> El 13/01/16 a les 13.46, Jan Beulich ha escrit:
>>> On 13.01.16 at 13:32, wrote:
> tools/libxc/xc_dom_elfloader.c | 2 +-
> xen/common/libelf/libelf-dominfo.c | 1 +
>>
On 13/01/16 13:08, Jan Beulich wrote:
On 13.01.16 at 14:05, wrote:
>> On 13/01/16 13:02, Jan Beulich wrote:
>> On 13.01.16 at 13:52, wrote:
El 13/01/16 a les 13.46, Jan Beulich ha escrit:
On 13.01.16 at 13:32, wrote:
>> tools/libxc/xc_dom_elfloader.c | 2 +-
>>
Markus Armbruster writes:
> Stefano Stabellini writes:
>
>> On Thu, 17 Dec 2015, Markus Armbruster wrote:
>>> Cc: Stefano Stabellini
>>> Cc: xen-de...@lists.xensource.com
>>> Signed-off-by: Markus Armbruster
>>> ---
>>> xen-hvm.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff
On Mon, Jan 04, 2016 at 12:33:29PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
ping ?
Thanks.
>
> Please pull in your "for-4.5/drivers" branch the following branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.5
>
> which is based on "bcache: Change
On Wed, 13 Jan 2016, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Stefano Stabellini writes:
> >
> >> On Thu, 17 Dec 2015, Markus Armbruster wrote:
> >>> Cc: Stefano Stabellini
> >>> Cc: xen-de...@lists.xensource.com
> >>> Signed-off-by: Markus Armbruster
> >>> ---
> >>> xen-hvm
Introduce an option where the user can modifiy the maximum number of
supported physical CPUs.
Signed-off-by: Doug Goldstein
---
xen/arch/Kconfig | 8
xen/arch/arm/Kconfig | 2 ++
xen/arch/x86/Kconfig | 2 ++
3 files changed, 12 insertions(+)
create mode 100644 xen/arch/Kconfig
dif
If the frontend sets out_cons to a value higher than out_prod, it will
cause xenfb_handle_events to loop about 2^32 times. Avoid that by using
better checks at the beginning of the function.
Signed-off-by: Stefano Stabellini
Reported-by: Ling Liu
---
Changes in v3:
- fix typo
---
diff --git
Hey,
We have some libxc calls for onlining/offlining the CPU and they
are quite good for testing how well Xen behaves without say
doing an S3 suspend or such.
It occurred to me that it would be nice to have them hook up in
libxl/xl but I am not exactly sure what the right command line would be?
On Xen MSIs can be remapped into pirqs, which are a type of event
channels. It's mostly for the benefit of PCI passthrough devices, to
avoid the overhead of interacting with the emulated lapic.
However remapping interrupts and MSIs is also supported for emulated
devices, such as the e1000 and virt
On 13/01/16 14:53, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> We have some libxc calls for onlining/offlining the CPU and they
> are quite good for testing how well Xen behaves without say
> doing an S3 suspend or such.
>
> It occurred to me that it would be nice to have them hook up in
> libxl/xl but
flight 77932 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3)broken REGR. vs. 60684
test-amd64
On 11/01/16 15:55, Aravind Gopalakrishnan wrote:
> On 9/22/2015 8:06 AM, Jan Beulich wrote:
>> ... in anticipation of this possibly going to get used by guests for
>> basic thinks like memset() or clearing or pages.
>>
>> Since the emulation doesn't use clzero itself, checking the guest's
>> CPUID
On 01/13/2016 07:05 AM, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 04, 2016 at 12:33:29PM -0500, Konrad Rzeszutek Wilk wrote:
Hey Jens,
ping ?
Pulled, sorry for the delay, I had some vacation post New Years that I
still haven't caught fully up on.
--
Jens Axboe
___
On 12/01/16 15:19, Jan Beulich wrote:
On 12.01.16 at 12:55, wrote:
>> On 12/01/16 10:08, Jan Beulich wrote:
>>> This went unnoticed until a backport of this to an older Xen got used,
>>> causing migration of guests enabling this VM assist to fail, because
>>> page table pinning there preceeds
>>> On 13.01.16 at 16:25, wrote:
> On 12/01/16 15:19, Jan Beulich wrote:
> On 12.01.16 at 12:55, wrote:
>>> On 12/01/16 10:08, Jan Beulich wrote:
This went unnoticed until a backport of this to an older Xen got used,
causing migration of guests enabling this VM assist to fail, becau
On Wed, Jan 13, 2016 at 03:15:20PM +, Andrew Cooper wrote:
> On 13/01/16 14:53, Konrad Rzeszutek Wilk wrote:
> > Hey,
> >
> > We have some libxc calls for onlining/offlining the CPU and they
> > are quite good for testing how well Xen behaves without say
> > doing an S3 suspend or such.
> >
> >
Cc: Stefano Stabellini
Cc: xen-de...@lists.xensource.com
Signed-off-by: Markus Armbruster
Message-Id: <1450370121-5768-14-git-send-email-arm...@redhat.com>
---
xen-hvm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen-hvm.c b/xen-hvm.c
index 3d78a0c..2a93390 100644
--- a/xen-hvm.c
flight 77933 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77933/
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
test-amd64-amd64-
Signed-off-by: Boris Ostrovsky
---
xen/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index d30d251..3699b20 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -109,7 +109,7 @@ _clean: delete-unfresh-files
.PHONY: _distclean
_distcl
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I would like to comment because it's not
clear to me what's the best direction to take.
1. HVM CPUID and Dom0.
Sadly the way CPUID is handled inside of Xen varies between PV and HVM.
On P
On 1/13/16 4:46 AM, Jan Beulich wrote:
> With xen/Makefile including include/config/auto.conf.cmd, environment
> variables checked in the latter must be available at the time of
> inclusion of that file, and hence must be populated in xen/Makefile
> rather than by passing to or inside xen/tools/kco
On 1/13/16 9:55 AM, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
> ---
> xen/Makefile |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/xen/Makefile b/xen/Makefile
> index d30d251..3699b20 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -109,7 +109,7
On 13/01/16 15:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
I think Andy's pendi
On 13/01/16 16:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CP
On 13/01/16 15:36, Jan Beulich wrote:
On 13.01.16 at 16:25, wrote:
>> On 12/01/16 15:19, Jan Beulich wrote:
>> On 12.01.16 at 12:55, wrote:
On 12/01/16 10:08, Jan Beulich wrote:
> This went unnoticed until a backport of this to an older Xen got used,
> causing migration of g
El 13/01/16 a les 16.56, Juergen Gross ha escrit:
> On 13/01/16 16:49, Roger Pau Monné wrote:
>> b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU
>> and from the Xen domain builder for HVMlite Dom0. This again implies
>> some functional duplication of MTRR related code, since
El 13/01/16 a les 16.54, David Vrabel ha escrit:
> On 13/01/16 15:49, Roger Pau Monné wrote:
>> 2. HVM MTRR and Dom0.
>>
>> MTRR ranges are initialised from hvmloader, which means that although we
>> expose the MTRR functionality to HVMlite guests (and AFAICT the
>> functionality is fully complete/
>>> On 13.01.16 at 16:54, wrote:
> On 13/01/16 15:49, Roger Pau Monné wrote:
>> While working on a HVMlite Dom0 implementation I've found a couple of
>> loose ends with the design that I would like to comment because it's not
>> clear to me what's the best direction to take.
>>
>> 1. HVM CPUID an
>>> On 13.01.16 at 16:49, wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CPUID is h
On 13/01/16 17:01, Roger Pau Monné wrote:
> El 13/01/16 a les 16.56, Juergen Gross ha escrit:
>> On 13/01/16 16:49, Roger Pau Monné wrote:
>>> b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU
>>> and from the Xen domain builder for HVMlite Dom0. This again implies
>>> some fu
>>> On 13.01.16 at 17:00, wrote:
> On 13/01/16 15:36, Jan Beulich wrote:
> On 13.01.16 at 16:25, wrote:
>>> On 12/01/16 15:19, Jan Beulich wrote:
>>> On 12.01.16 at 12:55, wrote:
> On 12/01/16 10:08, Jan Beulich wrote:
>> This went unnoticed until a backport of this to an older X
On 13/01/16 15:49, Roger Pau Monné wrote:
> Hello,
>
> While working on a HVMlite Dom0 implementation I've found a couple of
> loose ends with the design that I would like to comment because it's not
> clear to me what's the best direction to take.
>
> 1. HVM CPUID and Dom0.
>
> Sadly the way CPUID
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
>> Hello,
>>
>> While working on a HVMlite Dom0 implementation I've found a couple of
>> loose ends with the design that I would like to comment because it's not
>> clear to me what's the best direction to take.
>>
>> 1. HVM C
flight 77934 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 5 xen-install fail REGR. vs. 77871
Regressions which are reg
>>> On 13.01.16 at 17:17, wrote:
> On 13/01/16 16:13, Jan Beulich wrote:
> On 13.01.16 at 16:49, wrote:
>>> Hello,
>>>
>>> While working on a HVMlite Dom0 implementation I've found a couple of
>>> loose ends with the design that I would like to comment because it's not
>>> clear to me what's
>>> On 13.01.16 at 13:32, wrote:
> The BSP will be marked as initialised after hvm_load_cpu_ctxt has loaded the
> initial state, which is called from the toolstack during domain creation.
But the comment that you remove says explicitly that this isn't a
requirement.
Jan
> Signed-off-by: Roger P
On 13/01/16 16:26, Jan Beulich wrote:
On 13.01.16 at 17:17, wrote:
>> On 13/01/16 16:13, Jan Beulich wrote:
>> On 13.01.16 at 16:49, wrote:
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I would like to com
>>> On 13.01.16 at 13:32, wrote:
> The HVMlite series removed the initialization of the emulated PIT for PV
> guests, but the handler was still reachable, which means a PV guests can
> crash Xen if it pokes at IO ports 0x42, 0x43 or 0x61. Completely remove the
> PV PIT handler and move the PIT ini
Hi all,
I just put together the booking page for the next Hackathon. See
http://wiki.xenproject.org/wiki/Hackathon/April2016 for more information.
* If you are a maintainer or otherwise a core member of the community, just add
yourself to the Confirmed Attendees section stating your name and org
>>> On 13.01.16 at 13:32, wrote:
> Only intercept accesses to IO port 0xcf8 if there's at least one IOREQ
> server, otherwise it makes no sense since the only code that uses the value
> stored by hvm_access_cf8 is the IOREQ server.
Afaict an ioreq server could also attach subsequently - Paul?
Ja
Hello.
I tried to fix next error message:
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 13/01/16 16:38, Jan Beulich wrote:
On 13.01.16 at 13:32, wrote:
>> Only intercept accesses to IO port 0xcf8 if there's at least one IOREQ
>> server, otherwise it makes no sense since the only code that uses the value
>> stored by hvm_access_cf8 is the IOREQ server.
> Afaict an ioreq server
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 13 January 2016 16:39
> To: Paul Durrant; Roger Pau Monne
> Cc: Andrew Cooper; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH 5/5] x86/HVM: don't setup an intercept handler for IO
> port 0xcf8 unconditionally
>>> On 23.12.15 at 09:25, wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -28,6 +28,11 @@
> #include "vtd.h"
> #include "extern.h"
>
> +static int __read_mostly iommu_qi_timeout_ms = 1;
I'll take the liberty to convert this to "unsigned in
>>> On 23.12.15 at 09:25, wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -28,6 +28,11 @@
> #include "vtd.h"
> #include "extern.h"
>
> +static int __read_mostly iommu_qi_timeout_ms = 1;
> +integer_param("iommu_qi_timeout_ms", iommu_qi_timeo
On 01/13/2016 11:30 AM, Andrew Cooper wrote:
On 13/01/16 16:26, Jan Beulich wrote:
On 13.01.16 at 17:17, wrote:
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
Hello,
While working on a HVMlite Dom0 implementation I've found a couple of
loose ends with the design that I
On 13/01/16 17:03, Boris Ostrovsky wrote:
> On 01/13/2016 11:30 AM, Andrew Cooper wrote:
>> On 13/01/16 16:26, Jan Beulich wrote:
>> On 13.01.16 at 17:17, wrote:
On 13/01/16 16:13, Jan Beulich wrote:
On 13.01.16 at 16:49, wrote:
>> Hello,
>>
>> While working on a HVM
El 13/01/16 a les 17.29, Jan Beulich ha escrit:
On 13.01.16 at 13:32, wrote:
>> The BSP will be marked as initialised after hvm_load_cpu_ctxt has loaded the
>> initial state, which is called from the toolstack during domain creation.
>
> But the comment that you remove says explicitly that t
Add support for the newly added kernel memory auto onlining policy to Xen
ballon driver.
Suggested-by: Daniel Kiper
Signed-off-by: Vitaly Kuznetsov
---
Changes since v4:
- 'dom0' -> 'control domain', 'domU' -> 'target domain' in Kconfig
[David Vrabel]
- always call add_memory_resource() with m
Changes since v4:
Patch 1:
- Use memory_block_change_state() through walk_memory_range() instead of
online_pages() to correctly handle possible failures [David Rientjes]
- Minor memory-hotplug.txt changes (keep the old title, explicitly word
that we have a global policy here) [David Rientjes, D
Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
to make this happen automatically. This is not a great solution
On 01/13/2016 02:45 AM, Will Deacon wrote:
On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:
I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:
P0:
Wx = 1
P1:
Rx == 1
Wy = 1
P2:
Ry == 1
Rx = 0
flight 77945 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77945/
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 5 xen-install fail REGR.
vs. 77892
test-amd64
flight 77978 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
Hello David Vrabel,
The patch a4cdb556cae0: "xen/gntdev: add ioctl for grant copy" from
Dec 2, 2014, leads to the following static checker warning:
drivers/xen/gntdev.c:775 gntdev_get_page()
warn: mask and shift to zero
drivers/xen/gntdev.c
761 static int gntdev_get_page(stru
On Wed, Jan 13, 2016 at 06:32:29PM +0100, Vitaly Kuznetsov wrote:
> Currently, all newly added memory blocks remain in 'offline' state unless
> someone onlines them, some linux distributions carry special udev rules
> like:
>
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
> ATTR{sta
On Wed, Jan 13, 2016 at 06:32:30PM +0100, Vitaly Kuznetsov wrote:
> Add support for the newly added kernel memory auto onlining policy to Xen
> ballon driver.
>
> Suggested-by: Daniel Kiper
> Signed-off-by: Vitaly Kuznetsov
In general Reviewed-by: Daniel Kiper
but one nitpick below...
Thank yo
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
> I ask HW team about it but I have a question - has it any relationship with
> replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?
Of course. If you cannot explain the semantics of the primitives you
introduce, how can we ju
On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
I ask HW team about it but I have a question - has it any relationship with
replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?
Of course. If you cannot explain the semantics o
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-rumpuserxen-i386
testid guest-start
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditi
flight 38630 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38630/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38595
jobs:
build-amd64 pass
build-armhf
On 01/13/2016 02:45 AM, Will Deacon wrote:
I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:
P0:
Wx = 1
P1:
Rx == 1
Wy = 1
P2:
Ry == 1
Rx = 0
So are you saying that this is also forbidden?
Imagine that P0
This run is configured for baseline tests only.
flight 38629 qemu-upstream-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 10 gu
flight 77965 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77965/
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-m
This run is configured for baseline tests only.
flight 38631 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38631/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-
1 - 100 of 122 matches
Mail list logo
