Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.
Signed-off-by: Chunyan Liu
Acked-by: Ian Jackson
---
tools/libxl/libxl_internal.h | 4 +++
tools/libxl/libxl_utils.c| 74
2 f
Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usbctrl-attach test_vm version=1 ports=8
#xl usb-list test_vm
will show the usb controllers and port usage unde
For some device type, device removal operation needs to be
handled specially, like usbctrl, it needs to remove all usb
devices under it first, then remove usbctrl. Extend
DEFINE_DEVICE_REMOVE to support generic and custom way
For those need to be handled specially, call
DEFINE_DEVICE_REMOVE_CUSTOM,
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 controllers and usb devices in config file
like t
This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.
Changes to V14:
* reorder usbdev_remove to 3 steps (unassign, remove xenstore, rebind to
original driver (patch 4/6)
V14:
http://lists.xenpro
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Simon Cao
Signed-off-by: George Dunlap
Signed-off-by: Chunyan Liu
---
Changes:
reorder usbdev_r
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Reviewed-by: Wei Liu
Acked-by: Ian Jackson
---
tools/libxl/libxl.c | 5 ++---
tools/libxl/libxl_internal.h | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 833fd4
The hypervisor might return EBUSY when trying to remove a cpu from a
cpupool when a domain running in this cpupool has pinned a vcpu
temporarily. Do some retries in this case, perhaps the situation
cleans up.
Signed-off-by: Juergen Gross
---
tools/libxc/xc_cpupool.c | 13 -
1 file ch
Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
to achieve this by pinning the running thread to cpu 0, but in Dom0
this is not enough: the vcpu must be pinned to physical cpu 0 via
Xen, too.
Add a stable hypercal
Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
to achieve this by pinning the running thread to cpu 0, but in Dom0
this is not enough: the vcpu must be pinned to physical cpu 0 via
Xen, too.
This patch series add
When taking cpus offline for suspend or bringing them online on resume
again the scheduler might issue debug messages when temporarily
breaking vcpu affinity or restoring the original affinity settings.
The resume message can be removed completely, while the message when
breaking affinity should o
>>> On 01.03.16 at 06:39, wrote:
>
>> -Original Message-
>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>> Sent: Monday, February 29, 2016 9:52 PM
>> To: Jan Beulich ; George Dunlap
>> ; Wu, Feng
>> Cc: Andrew Cooper ; Tian, Kevin
>> ; xen-devel@lists.xen.org; Keir Fraser
>
>>> On 01.03.16 at 03:35, wrote:
>
> On 2016/2/29 22:36, Jan Beulich wrote:
> On 29.02.16 at 15:25, wrote:
>>> > On Mon, 29 Feb 2016, Jan Beulich wrote:
>> Also it doesn't look very nice to me to (ab)use xz's CRC32 code
>> here; I don't know who has suggested doing so.
>>> >
>>>
>>> On 01.03.16 at 07:27, wrote:
>> From: Jan Beulich
>> Sent: Thursday, February 25, 2016 8:28 PM
>>
>> >>
>> >> Pending confirmation on FIP register width by at least Intel,
>> >> Reviewed-by: Jan Beulich
>> >
>> > For Intel CPUs, FIP is 48-bits internally and newer CPUs have FPCSDS and
>> >
On Mon, Feb 29, 2016 at 9:10 PM, Doug Goldstein wrote:
> On 2/23/16 3:33 AM, George Dunlap wrote:
>> On Mon, Feb 22, 2016 at 7:03 PM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Mon, Feb 22, 2016 at 06:39:26PM +, Lars Kurth wrote:
> On 22 Feb 2016, at 18:34, Doug Goldstein wrote:
>
>
El 19/2/16 a les 19:01, Roger Pau Monne ha escrit:
> This was introduced by 97ee1f (~5 years ago), but was probably never
> surfaced because most people used regular files as CDROM images, so the PHY
> backend was actually never selected. A year ago this was changed, and now
> regular RAW files are
On 02/25/2016 11:56 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:20AM +0800, Wen Congyang wrote:
>> Secondary vm is running in colo mode. So we will do
>> the following things again and again:
>> 1. Resume secondary vm
>>a. Send CHECKPOINT_SVM_READY to master.
>>b. If it is not the fi
>>> On 29.02.16 at 21:29, wrote:
> Signed-off-by: Shannon Zhao
> ---
> v7: fix coding style
Thanks, almost (see below).
> --- /dev/null
> +++ b/xen/arch/arm/acpi/lib.c
> @@ -0,0 +1,53 @@
> +/*
> + * lib.c - Architecture-Specific Low-Level ACPI Support
> + *
> + * Copyright (C) 2015, Shannon Z
>>> On 01.03.16 at 02:39, wrote:
> This patch implements a common function hvm_scale_tsc() to scale TSC by
> using TSC scaling information collected by architecture code.
>
> Signed-off-by: Haozhong Zhang
> Acked-by: Boris Ostrovsky for SVM bits
Reviewed-by: Jan Beulich
> ---
> Mixing named
On 29/02/16 13:33, Jan Beulich wrote:
On 29.02.16 at 04:00, wrote:
>> This is the core logic handling for VT-d posted-interrupts. Basically it
>> deals with how and when to update posted-interrupts during the following
>> scenarios:
>> - vCPU is preempted
>> - vCPU is slept
>> - vCPU is block
This run is configured for baseline tests only.
flight 44200 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 5 xen-build
>>> On 29.02.16 at 21:39, wrote:
> @@ -50,11 +52,13 @@ struct hvm_irq {
> /* Virtual interrupt and via-link for paravirtual platform driver. */
> uint32_t callback_via_asserted;
> union {
> +/* These MUST match with HVM_PARAM_CALLBACK_IRQ types. */
> enum {
> -
>>> On 29.02.16 at 16:10, wrote:
> On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
>> What is the correct way to identify a Xen PV domU in the kenrel?
>> devmem_is_allowed() used to disable access to pages < 256 in domU.
>> With pvops this check was removed, or never ported forward.
>
On Mon, Feb 29, 2016 at 10:35:56AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 29, 2016 at 11:17:05AM +, Wei Liu wrote:
> > NOTE: We are one month away from freeze. Features that wish to be in 4.7
> > must
> > be posted to xen-devel by March 18.
> >
> > This email only tracks big items
Unfortunately, we were rejected again. What is notable, is that the number of
mentoring organisations is much smaller than in the past. However, this year
the Linux Foundation and most distros (with the exception of CentOS, which was
in last year) are included. Libvirt is included also, but KVM
On Tue, Mar 01, 2016 at 12:54:09AM -0700, Jan Beulich wrote:
> >>> On 29.02.16 at 19:12, wrote:
> > I read the XSA-154 patch and think a little bit on whether making
> > dedicated hypercall is feasible.
> >
> > 1. The patch for XSA-154 mentions that only MMIO mappings with
> >inconsistent att
>>> On 01.03.16 at 11:52, wrote:
> On Tue, Mar 01, 2016 at 12:54:09AM -0700, Jan Beulich wrote:
>> >>> On 29.02.16 at 19:12, wrote:
>> > I read the XSA-154 patch and think a little bit on whether making
>> > dedicated hypercall is feasible.
>> >
>> > 1. The patch for XSA-154 mentions that only M
David, Wei,
Ping?
Paul
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 26 February 2016 17:03
> To: xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Wei Liu; David Vrabel; Jan Beulich
> Subject: Re: [Xen-devel] [PAT
>>> On 01.03.16 at 10:02, wrote:
> @@ -752,14 +766,20 @@ static int vcpu_set_affinity(
> struct vcpu *v, const cpumask_t *affinity, cpumask_t *which)
> {
> spinlock_t *lock;
> +int ret = 0;
>
> lock = vcpu_schedule_lock_irq(v);
>
> -cpumask_copy(which, affinity);
> +
On Thu, Feb 25, 2016 at 02:56:04PM +, Anthony PERARD wrote:
> A user can provide a different ACPI tables than the default one by using
> the existing "acpi_firmware" xl's config option or the field
> u.hvm.acpi_firmware.
>
> libxl will check if the provided table is a DSDT or not.
>
Accordin
On Thu, Feb 25, 2016 at 02:55:59PM +, Anthony PERARD wrote:
> This patch use xc_dom_alloc_segment() to allocate the memory space for the
> ACPI modules and the SMBIOS modules. This is to replace the arbitrary
> placement of 1MB after the hvmloader image.
>
> In later patches, while trying to l
On Thu, Feb 25, 2016 at 02:56:01PM +, Anthony PERARD wrote:
> Those paths are to be used by libxl, in order to load the firmware in
> memory. If a system path is not define, then this default to the Xen
> firmware directory.
>
> Signed-off-by: Anthony PERARD
>
There is already --with-system
On Thu, Feb 25, 2016 at 02:56:00PM +, Anthony PERARD wrote:
> This adds two new firmware module, bios_module and full_acpi_module. They
> are loaded in the guest memory and final location is provided to hvmloader
> via the hvm_start_info struct.
>
> This patch create the hvm_start_info struct
On Thu, Feb 25, 2016 at 02:56:03PM +, Anthony PERARD wrote:
> The path to the BIOS blob can be override by the xl's bios_override option,
> or provided by u.hvm.bios_firmware in the domain_build_info struct by other
> libxl user.
>
> Signed-off-by: Anthony PERARD
>
> ---
> Change in V3:
> -
On 01/03/16 09:02, Juergen Gross wrote:
> Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
> called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
> to achieve this by pinning the running thread to cpu 0, but in Dom0
> this is not enough: the vcpu must be pinned to phy
On 01/03/16 12:27, Jan Beulich wrote:
On 01.03.16 at 10:02, wrote:
>> @@ -752,14 +766,20 @@ static int vcpu_set_affinity(
>> struct vcpu *v, const cpumask_t *affinity, cpumask_t *which)
>> {
>> spinlock_t *lock;
>> +int ret = 0;
>>
>> lock = vcpu_schedule_lock_irq(v);
>>
On Tue, Mar 01, 2016 at 10:02:13AM +0100, Juergen Gross wrote:
> The hypervisor might return EBUSY when trying to remove a cpu from a
> cpupool when a domain running in this cpupool has pinned a vcpu
> temporarily. Do some retries in this case, perhaps the situation
> cleans up.
>
> Signed-off-by:
On 01/03/16 12:55, David Vrabel wrote:
> On 01/03/16 09:02, Juergen Gross wrote:
>> Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
>> called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
>> to achieve this by pinning the running thread to cpu 0, but in Dom0
>> this
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
On 01/03/16 12:58, Wei Liu wrote:
> On Tue, Mar 01, 2016 at 10:02:13AM +0100, Juergen Gross wrote:
>> The hypervisor might return EBUSY when trying to remove a cpu from a
>> cpupool when a domain running in this cpupool has pinned a vcpu
>> temporarily. Do some retries in this case, perhaps the sit
On Tue, 2016-03-01 at 12:58 +0100, Juergen Gross wrote:
> On 01/03/16 12:55, David Vrabel wrote:
> >
> > On 01/03/16 09:02, Juergen Gross wrote:
> > >
> > > Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
> > > called on physical cpu 0 only. Linux drivers like dcdbas or i8k
> > >
On Thu, Feb 25, 2016 at 08:25:17PM +0100, Roger Pau Monne wrote:
> This code is extracted from the FreeBSD blkfront implementation.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.x
On Thu, Feb 25, 2016 at 08:25:16PM +0100, Roger Pau Monne wrote:
> The current code in libxl assumed that vdev is equal to local device, but
> this is only true for Linux systems. In other OSes the local device can use
> a nomenclature completely different from the virtual device one.
>
> Move the
On Thu, Feb 25, 2016 at 08:25:12PM +0100, Roger Pau Monne wrote:
> FreeBSD blkback uses the physical-device xenstore node in order to fetch the
> path to the underlying backing storage (either a block device or raw image).
> This node is set by the hotplug scripts.
>
> Signed-off-by: Roger Pau Mon
On Thu, Feb 25, 2016 at 08:25:15PM +0100, Roger Pau Monne wrote:
> Allow FreeBSD to execute hotplug scripts when attaching disk devices.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Ian Jackson
> Cc: Ian Campbell
> Cc: Wei Liu
> ---
> tools/libxl/libxl_freebsd.c | 114
> +++
On Thu, Feb 25, 2016 at 08:25:14PM +0100, Roger Pau Monne wrote:
> This is the default hotplug script for block devices. Its only job is to
> copy the "params" blkback xenstore node to "physical-device".
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
_
On Thu, Feb 25, 2016 at 08:25:13PM +0100, Roger Pau Monne wrote:
> Linux and NetBSD will return the device major and minor numbers encoded in
> hex and separated by a ":". FreeBSD on the other hand returns the path to
> the block device or image file.
>
> Signed-off-by: Roger Pau Monné
The code
On Thu, Feb 25, 2016 at 08:25:18PM +0100, Roger Pau Monne wrote:
> The fields that are printed might not be set in the case of a failure, which
> generates a segmentation fault.
>
Right, I can see how this can fail.
In device_addrm_aocomplete we check if aodev is set. But I think that's
a bit ov
On Tue, 1 Mar 2016, Jan Beulich wrote:
> >>> On 01.03.16 at 03:35, wrote:
>
> >
> > On 2016/2/29 22:36, Jan Beulich wrote:
> > On 29.02.16 at 15:25, wrote:
> >>> > On Mon, 29 Feb 2016, Jan Beulich wrote:
> >> Also it doesn't look very nice to me to (ab)use xz's CRC32 code
> >> her
On Tue, Mar 01, 2016 at 12:59:50PM +0100, Roger Pau Monne wrote:
> 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 a
On Mon, Feb 29, 2016 at 10:45:51AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 23, 2016 at 10:30:31AM +, Ian Campbell wrote:
> > On Wed, 2016-02-17 at 10:39 +, Ian Campbell wrote:
> > > We assert that nullfd if not std{in,out,err} since that would result
> > > in closing one of the ju
This run is configured for baseline tests only.
flight 44201 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44201/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Tuesday, March 1, 2016 6:17 PM
> To: Jan Beulich ; George Dunlap
> ; Wu, Feng
> Cc: Andrew Cooper ; Dario Faggioli
> ; Tian, Kevin ; xen-
> de...@lists.xen.org; Keir Fraser
> Subject: Re: [Xen-devel] [P
El 29/2/16 a les 17:45, George Dunlap ha escrit:
> On 29/02/16 16:08, Roger Pau Monné wrote:
>> El 29/2/16 a les 15:26, George Dunlap ha escrit:
>>> On 29/02/16 12:18, Roger Pau Monné wrote:
El 29/2/16 a les 13:15, George Dunlap ha escrit:
> On Thu, Feb 25, 2016 at 7:25 PM, Roger Pau Monne
flight 84610 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 84518
test-armhf-armhf-xl-
Olaf Hering writes ("Re: [Xen-devel] Call for tools backport requests for 4.5.x
(Re: 4.5.3 preparations)"):
> On Mon, Feb 29, Olaf Hering wrote:
> > 77fec3a tools/console: correct make dependencies for _paths.h
>
> Sorry, I read the Subject as 4.6.x ...
Right. Well, actually, I'm happy right no
Olaf Hering writes ("Re: [Xen-devel] Call for tools backport requests for 4.5.x
(Re: 4.5.3 preparations)"):
> On Mon, Feb 29, Ian Jackson wrote:
>
> > I rely on someone (which might be the maintainer or submitter, or
> > anyone else) noticing that a fix ought to be considered for backport
> > and
George Dunlap writes ("Re: [PATCH 7/8] tools/xenalyze: Fix multiple instances
of *HYPERCALL_MAX"):
> On 26/02/16 12:33, Ian Jackson wrote:
> > Does this produce a build error if HYPERCALL_MAX is too small ?
>
> You mean, if it's smaller than at least one of the indexes in the array
> initializati
Ian Campbell writes ("[PATCH v2] xl: close nullfd after dup2'ing it to stdin"):
> We assert that nullfd if not std{in,out,err} since that would result
> in closing one of the just dup2'd fds. For this to happen
> std{in,out,err} would have needed to be closed, at which point all
> sorts of other th
flight 84615 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 60684
test-amd64
On Mon, Feb 29, 2016 at 02:59:26PM -0500, Konrad Rzeszutek Wilk wrote:
> Document the save and suspend mechanism.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> tools/libxc/include/xenctrl.h | 52
> +++
> 1 file changed, 52 insertions(+)
>
> diff --git
On Mon, Feb 29, 2016 at 12:59 PM, Konrad Rzeszutek Wilk
wrote:
>> > Hey!
>> >
>> > CC-ing Elena.
>>
>> I think you forgot you cc.ed her..
>> Anyway, let's cc. her now... :-)
>>
>> >
>> >> We are measuring the execution time between native machine environment
>> >> and xen virtualization environmen
Harmandeep Kaur writes ("[PATCH v4] libxl: handle failure of xc_version() in
libxl_get_version_info()"):
> Check the return value of xc_version() and return NULL if it
> fails. libxl_get_version_info() can also return NULL now.
>
> Callers of the function libxl_get_version_info() are already
> pr
Haozhong Zhang writes ("Re: [RFC Design Doc] Add vNVDIMM support for Xen"):
> On 02/29/16 05:04, Jan Beulich wrote:
> > Which will involve adding how much new code to it?
>
> Because hvmloader only accepts AML device rather than arbitrary objects,
> only code that builds the outmost part of AML de
flight 84614 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84614/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 84523
build-i386
Hi everyone,
we have a first publicly available prototype of the code review dashboard and I
am looking for input. You can access the dashboard via:
- kibana-xen.bitergia.com
There are a couple of links on the top, which get you to two different
dashboards
- Dash 1 contains panels for A
On 02/29/2016 06:50 PM, Andy Lutomirski wrote:
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 91ddae732a36..c6ef4da8e4f4 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -979,6 +979,31 @@ static void identify_cpu(struct cpuinfo_x86 *c
On 01/03/16 12:15, Dario Faggioli wrote:
> On Tue, 2016-03-01 at 12:58 +0100, Juergen Gross wrote:
>> On 01/03/16 12:55, David Vrabel wrote:
>>>
>>> On 01/03/16 09:02, Juergen Gross wrote:
Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
called on physical cpu 0 only.
Haozhong Zhang writes ("[PATCH v6 5/5] docs: Add descriptions of TSC scaling in
xl.cfg and tscmode.txt"):
> Signed-off-by: Haozhong Zhang
> Reviewed-by: Kevin Tian
This seems relatively clear. I'm happy to take your word for it that
this is the behaviour.
If anyone feels that the docs in this
>>> On 01.03.16 at 15:09, wrote:
> Haozhong Zhang writes ("[PATCH v6 5/5] docs: Add descriptions of TSC scaling
> in xl.cfg and tscmode.txt"):
>> Signed-off-by: Haozhong Zhang
>> Reviewed-by: Kevin Tian
>
> This seems relatively clear. I'm happy to take your word for it that
> this is the beh
Hi all,
I would like to propose Julien Grall (julien.gr...@arm.com) as
co-maintainer for Xen on ARM. His track record of contributions to the
project is outstanding and I think speaks for itself.
Julien made multiple public presentations about Xen on ARM at Xen
Developer Summit and Linaro Connect
On Tue, Mar 01, 2016 at 03:25:55AM -0700, Jan Beulich wrote:
> >>> On 29.02.16 at 21:39, wrote:
> > @@ -50,11 +52,13 @@ struct hvm_irq {
> > /* Virtual interrupt and via-link for paravirtual platform driver. */
> > uint32_t callback_via_asserted;
> > union {
> > +/* These MU
On Tue, Mar 01, 2016 at 03:38:55AM -0700, Jan Beulich wrote:
> >>> On 29.02.16 at 16:10, wrote:
> > On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
> >> What is the correct way to identify a Xen PV domU in the kenrel?
> >> devmem_is_allowed() used to disable access to pages < 256 in d
On Tue, Mar 01, 2016 at 02:29:30PM +, Stefano Stabellini wrote:
> Hi all,
>
> I would like to propose Julien Grall (julien.gr...@arm.com) as
> co-maintainer for Xen on ARM. His track record of contributions to the
> project is outstanding and I think speaks for itself.
>
> Julien made multipl
On Tue, 1 Mar 2016, Shannon Zhao wrote:
> On 2016/2/29 20:13, Stefano Stabellini wrote:
> > On Sun, 28 Feb 2016, Shannon Zhao wrote:
> >> > From: Shannon Zhao
> >> >
> >> > Estimate the memory required for loading acpi/efi tables in Dom0. Make
> >> > the length of each table aligned with 64bit. A
flight 44202 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44202/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail like 38733
test-amd64-amd
On 03/01/2016 09:34 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Mar 01, 2016 at 03:38:55AM -0700, Jan Beulich wrote:
On 29.02.16 at 16:10, wrote:
On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
What is the correct way to identify a Xen PV domU in the kenrel?
devmem_is_allowed() used
On Tue, 1 Mar 2016, Shannon Zhao wrote:
> On 2016/2/29 22:37, Stefano Stabellini wrote:
> > On Sun, 28 Feb 2016, Shannon Zhao wrote:
> >> > From: Shannon Zhao
> >> >
> >> > Create a few EFI memory descriptors to tell Dom0 the RAM region
> >> > information, ACPI table regions and EFI tables reserv
On Wed, Feb 24, 2016 at 09:03:29AM -0600, Doug Goldstein wrote:
> bcc/ld86/as86 are necessary when we build ROMBIOS. However if we do not
> build it (and are not building qemu-trad), the build requirements are
> overly strict and can lead to failures.
>
> Signed-off-by: Doug Goldstein
> Reviewed-
>>> On 01.03.16 at 14:51, wrote:
> Haozhong Zhang writes ("Re: [RFC Design Doc] Add vNVDIMM support for Xen"):
>> On 02/29/16 05:04, Jan Beulich wrote:
>> > Which will involve adding how much new code to it?
>>
>> Because hvmloader only accepts AML device rather than arbitrary objects,
>> only co
>>> On 01.03.16 at 15:57, wrote:
> On Tue, 1 Mar 2016, Shannon Zhao wrote:
>> On 2016/2/29 22:37, Stefano Stabellini wrote:
>> > On Sun, 28 Feb 2016, Shannon Zhao wrote:
>> >> > --- a/xen/common/efi/boot.c
>> >> > +++ b/xen/common/efi/boot.c
>> >> > @@ -1233,6 +1233,44 @@ void __init acpi_create_e
On Mon, Feb 29, Boris Ostrovsky wrote:
> Do you see any messages in hypervisor log (like "Bad L1 flags 10")?
Yes, with a debug build of xen.gz.
(XEN) mm.c:1882:d1v0 Bad L1 flags 10
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.x
On 29/02/16 10:28, Olaf Hering wrote:
> What is the correct way to identify a Xen PV domU in the kenrel?
> devmem_is_allowed() used to disable access to pages < 256 in domU.
> With pvops this check was removed, or never ported forward.
>
> Would this change be the correct fix?
I think the bug is
Ifdef'ing CONFIG_ARM in xen/arch/arm/efi/efi-boot.h is redundant, remove
the condition and simplify the ifdef's.
Signed-off-by: Stefano Stabellini
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index a6c3b69..c58caca 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch
On Tue, 1 Mar 2016, Shannon Zhao wrote:
> On 2016/2/29 22:15, Stefano Stabellini wrote:
> > On Sun, 28 Feb 2016, Shannon Zhao wrote:
> >> > From: Shannon Zhao
> >> >
> >> > Map all other tables to Dom0 using 1:1 mappings.
> >> >
> >> > Signed-off-by: Shannon Zhao
> >> > ---
> >> > v4: fix commi
On Tue, Mar 1, 2016 at 6:00 AM, Boris Ostrovsky
wrote:
> On 02/29/2016 06:50 PM, Andy Lutomirski wrote:
>>
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index 91ddae732a36..c6ef4da8e4f4 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/commo
(CC list adjusted)
Ian Campbell writes ("Re: [PATCH] tools: libxl: Simplify logic in
libxl__realloc"):
> On Fri, 2016-02-19 at 15:34 +, Ian Jackson wrote:
> > Replace the loop exit and separate test for loop overrun with an
> > assert in the loop body.
> >
> > This simplifies the code. It a
On Mon, 29 Feb 2016, Jan Beulich wrote:
> All,
>
> it just occurred to me that 4.5.2 has been a while back, and indeed
> 4.5.3 would be due later this week. This may be a little too eager,
> but I'd like to aim at getting this out at least some time next week.
> Besides what is in the tree already
>>> On 01.03.16 at 16:35, wrote:
> Ifdef'ing CONFIG_ARM in xen/arch/arm/efi/efi-boot.h is redundant, remove
> the condition and simplify the ifdef's.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Jan Beulich
Since you have no co-maintainer right now, and since the change
is pretty obviou
>>> On 01.03.16 at 16:44, wrote:
> On Mon, 29 Feb 2016, Jan Beulich wrote:
>> All,
>>
>> it just occurred to me that 4.5.2 has been a while back, and indeed
>> 4.5.3 would be due later this week. This may be a little too eager,
>> but I'd like to aim at getting this out at least some time next we
On 01/03/16 15:52, George Dunlap wrote:
> On 01/03/16 09:02, Juergen Gross wrote:
>> Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
>> called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
>> to achieve this by pinning the running thread to cpu 0, but in Dom0
>> this
On 01/03/16 09:02, Juergen Gross wrote:
> Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
> called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
> to achieve this by pinning the running thread to cpu 0, but in Dom0
> this is not enough: the vcpu must be pinned to phy
On Tue, 1 Mar 2016, Jan Beulich wrote:
> >>> On 01.03.16 at 16:44, wrote:
> > On Mon, 29 Feb 2016, Jan Beulich wrote:
> >> All,
> >>
> >> it just occurred to me that 4.5.2 has been a while back, and indeed
> >> 4.5.3 would be due later this week. This may be a little too eager,
> >> but I'd like
>>> On 25.02.16 at 15:56, wrote:
> All BIOS but ROMBIOS needs to be loaded via modules.
>
> ROMBIOS is handled as a special case.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lis
>>> On 25.02.16 at 15:56, wrote:
> --- a/tools/firmware/hvmloader/ovmf.c
> +++ b/tools/firmware/hvmloader/ovmf.c
> @@ -34,17 +34,10 @@
> #include
> #include
>
> -#define ROM_INCLUDE_OVMF
> -#include "roms.inc"
> -
> -#define OVMF_SIZE (sizeof(ovmf))
> #define OVMF_MAXOFFSET
Wei Liu writes ("Re: [PATCH v4 2/4] libxl: introduce
LIBXL_VGA_INTERFACE_TYPE_UNKNOWN"):
> On Tue, Feb 16, 2016 at 06:37:47PM +0100, Roger Pau Monne wrote:
> > And use it as the default value for the VGA kind. This allows libxl to set
> > it to the default value later on when the domain type is kn
>>> On 01.03.16 at 16:55, wrote:
> On 01/03/16 15:52, George Dunlap wrote:
>> On 01/03/16 09:02, Juergen Gross wrote:
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -271,6 +271,12 @@ int sched_move_domain(struct domain *d, struct cpupool
>>> *c)
>>> struct scheduler *
Ian Campbell writes ("[PATCH 1/2] xl: uptime: skip dom0 when calling
print_domU_uptime"):
> Dom0 is handled separately (via print_dom0_uptime) and the domU
> variant doesn't work for dom0 since libxl_vm_get_start_time() doesn't.
>
> Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
and queued
On Tue, 1 Mar 2016, Jan Beulich wrote:
> >>> On 01.03.16 at 16:35, wrote:
> > Ifdef'ing CONFIG_ARM in xen/arch/arm/efi/efi-boot.h is redundant, remove
> > the condition and simplify the ifdef's.
> >
> > Signed-off-by: Stefano Stabellini
>
> Reviewed-by: Jan Beulich
>
> Since you have no co-ma
>>> On 25.02.16 at 15:56, wrote:
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -365,8 +365,26 @@ int main(void)
>
> if ( bios->acpi_build_tables )
> {
> +const struct hvm_modlist_entry *acpi_module;
> +acp
1 - 100 of 190 matches
Mail list logo
