Do the allocation of page tables in a separate function. This will
allow to do the allocation at different times of the boot preparations
depending on the features the kernel is supporting.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
grub-core/loader/i386/xen.c | 91 +
Do the allocation of special pages (start info, console and xenbus
ring buffers) in a separate function. This will allow to do the
allocation at different times of the boot preparations depending on
the features the kernel is supporting.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
The loader for xen paravirtualized environment isn't callable multiple
times as it won't free any memory in case of failure.
Call grub_relocator_unload() as other modules do it before allocating
a new relocator or when unloading the module.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
Modify the page table construction to allow multiple virtual regions
to be mapped. This is done as preparation for removing the p2m list
from the initial kernel mapping in order to support huge pv domains.
This allows a cleaner approach for mapping the relocator page by
using this capability.
The
When loading a Xen pv-kernel avoid memory leaks in case of errors.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
V5: set grub_errno to GRUB_ERR_NONE to avoid false error reports as requested
by Daniel Kiper
---
grub-core/loader/i386/xen.c| 2 +-
grub-core/loader/i386/x
Do the p2m list allocation of the to be loaded kernel in a separate
function. This will allow doing the p2m list allocation at different
times of the boot preparations depending on the features the kernel
is supporting.
While at this remove superfluous setting of first_p2m_pfn and
nr_p2m_frames as
Various features and parameters of a pv-kernel are specified via
elf notes in the kernel image. Those notes are part of the interface
between the Xen hypervisor and the kernel.
Instead of using num,bers in the code when interpreting the elf notes
make use of the header supplied by Xen for that pur
Modern pvops linux kernels support a p2m list not covered by the
kernel mapping. This capability is flagged by an elf-note specifying
the virtual address the kernel is expecting the p2m list to be mapped
to.
In case the elf-note is set by the kernel don't place the p2m list
into the kernel mapping
Get actual version of include/xen/xen.h from the Xen repository in
order to be able to use constants defined there.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
include/xen/arch-x86/xen-x86_32.h | 22 +++
include/xen/arch-x86/xen-x86_64.h | 8 +--
include/xen/xen.h
The loader for xen paravirtualized environment is using lots of global
variables. Reduce the number by making them either local or by putting
them into a single state structure.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
grub-core/loader/i386/xen.c | 259 +++-
The Xen hypervisor supports starting a dom0 with large memory (up to
the TB range) by not including the initrd and p2m list in the initial
kernel mapping. Especially the p2m list can grow larger than the
available virtual space in the initial mapping.
The started kernel is indicating the support o
Modern pvops linux kernels support an initrd not covered by the initial
mapping. This capability is flagged by an elf-note.
In case the elf-note is set by the kernel don't place the initrd into
the initial mapping. This will allow to load larger initrds and/or
support domains with larger memory, a
>>> 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 attributes can cause system instability.
> 2. PV case is hard, but the devic
On 02/18/16 21:14, Konrad Rzeszutek Wilk wrote:
> > > > QEMU would always use MFN above guest normal ram and I/O holes for
> > > > vNVDIMM. It would attempt to search in that space for a contiguous range
> > > > that is large enough for that that vNVDIMM devices. Is guest able to
> > > > punch hole
> 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
> > thus we will always use the 64-bit save.
>
> -Original Message-
> From: Tian, Kevin
> Sent: Tuesday, March 1, 2016 1:25 PM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: Keir Fraser ; Jan Beulich ; Andrew
> Cooper ; George Dunlap
> ; Dario Faggioli
> Subject: RE: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling
>
>
> -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
> Subject: Re: [Xen-devel] [PATCH v14 1/2] v
> From: Paul Durrant
> Sent: Friday, February 26, 2016 6:19 PM
>
> This patch adds a new 'designs' subdirectory under docs as a repository
> for this and future design proposals. It also adjusts the docs
> Makefile to look in the new subdirectory.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Ke
> From: Wu, Feng
> Sent: Monday, February 29, 2016 11:00 AM
>
> 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 blocked
>
> When vCP
On 01/03/16 04:52, Andrei Borzenkov wrote:
> 29.02.2016 15:19, Juergen Gross пишет:
>> On 29/02/16 10:13, Juergen Gross wrote:
>>> On 25/02/16 19:33, Andrei Borzenkov wrote:
22.02.2016 16:14, Juergen Gross пишет:
> On 22/02/16 13:48, Daniel Kiper wrote:
>> On Mon, Feb 22, 2016 at 01:30
flight 84523 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84523/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 84204
test-amd64-i386-xl-qemuu-win
29.02.2016 17:41, Konrad Rzeszutek Wilk пишет:
> On Sun, Feb 28, 2016 at 08:10:33AM +0300, Andrei Borzenkov wrote:
>> 27.02.2016 23:33, Konrad Rzeszutek Wilk пишет:
>>> On Fri, Feb 26, 2016 at 07:15:52PM +0800, Fu Wei wrote:
Hi Andrei,
On 26 February 2016 at 18:50, Andrei Borzenkov
An expanded V2 of
https://www.redhat.com/archives/libvir-list/2016-February/msg00140.html
In V2, the feature is extended with a state='on|off' attribute to
allow differentiating the 'on' and 'off' states with not set (or hypervisor
default).
Obviously post 1.3.2 material. See individual patches
Until now, the libxl driver ignored any setting in domain XML
and deferred to libxl, which enables hap if not specified. While
this is a good default, it prevents disabling hap if desired.
This change allows disabling hap with . hap is
explicitly enabled with or
hap is enabled by default in xm and xl config and usually only
specified when it is desirable to disable hap (hap = 0). Change
the xm,xl <-> xml converter to behave similarly. I.e. only
produce 'hap = 0' when and vice versa.
Signed-off-by: Jim Fehlig
---
src/xenconfig/xen_common.c
Most hypervisors use Hardware Assisted Paging by default and don't
require specifying the feature in domain conf. But some hypervisors
support disabling HAP on a per-domain basis. To enable HAP by default
yet provide a knob to disable it, extend the feature with a
'state=on|off' attribute, similar
Hardware Assisted Paging is enabled by default in Xen. Change
the capabilities output to reflect this.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_conf.c | 2 +-
src/xen/xen_hypervisor.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl
flight 44198 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44198/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail REGR. vs.
38732
Regre
29.02.2016 15:19, Juergen Gross пишет:
> On 29/02/16 10:13, Juergen Gross wrote:
>> On 25/02/16 19:33, Andrei Borzenkov wrote:
>>> 22.02.2016 16:14, Juergen Gross пишет:
On 22/02/16 13:48, Daniel Kiper wrote:
> On Mon, Feb 22, 2016 at 01:30:30PM +0100, Juergen Gross wrote:
>> On 22/02/
>>> On 2/29/2016 at 06:14 PM, in message <56d419f6.8030...@citrix.com>, George
Dunlap wrote:
> On 26/02/16 12:09, Ian Jackson wrote:
> > George Dunlap writes ("Re: [Xen-devel] [PATCH V14 4/6] libxl: add pvusb
> API"):
> >> On Fri, Feb 19, 2016 at 10:39 AM, Chunyan Liu wrote:
> >>> + [...
flight 84518 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84518/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 9 debian-di-install fail in 84436 pass in 84518
test-armhf-armhf-libvirt-qcow2 5
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 reserved resions.
>> >
>> > Cc: Jan Beulich
>> > Signe
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.
>> >
>> > It was suggested by Julien.
>> >
>> > I
Hi,alls
Xen kernel may modify domu's memory but the domu can't know.I need to save
the memory before xen kernel modify it,so I want to save the memory in xen
kernel sapce.But I don't know how to get the address of domu's one page
memory.Could anybody tell me?
Thanks!
___
This run is configured for baseline tests only.
flight 44197 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44197/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 11 guest-start
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. Alloc the pages to store
>> > the new created EFI a
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
---
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Boris Ostrovsky
CC: Suravee Sut
On 29/02/2016 19:59, 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 a/tools/libxc/include/
x86_64 has very clean espfix handling on paravirt: espfix64 is set
up in native_iret, so paravirt systems that override iret bypass
espfix64 automatically. This is robust and straightforward.
x86_32 is messier. espfix is set up before the IRET paravirt patch
point, so it can't be directly condit
[v2 because I screwed up sending it really badly and it's not worth
trying to disentangle the mess]
Hi Luis-
As promised, here are these patches.
Borislav, if you're okay with this (ab)use of the cpufeatures stuff
and if they survive review, I'd be okay with them joining Luis'
series or going st
It no longer has any users.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/asm-offsets.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 84a7524b202c..5c042466f274 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86
On 03/01/2016 12:29 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [RFC PATCH] xen-block: introduces extra request to
> pass-through SCSI commands"):
>> [stuff suggesting use of PVSCSI instead]
>
> For the avoidance of doubt:
>
> 1. Thanks very much for bringing this proposal to us at the co
x86_64 has very clean espfix handling on paravirt: espfix64 is set
up in native_iret, so paravirt systems that override iret bypass
espfix64 automatically. This is robust and straightforward.
x86_32 is messier. espfix is set up before the IRET paravirt patch
point, so it can't be directly condit
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_64.S | 34 ++
arch/x86/include/asm/segment.h | 5 -
arch/x86/kernel/cpu/common.c | 2 ++
3 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/
On 03/01/2016 12:29 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [RFC PATCH] xen-block: introduces extra request to
> pass-through SCSI commands"):
>> [stuff suggesting use of PVSCSI instead]
>
> For the avoidance of doubt:
>
> 1. Thanks very much for bringing this proposal to us at the co
Hi Luis-
As promised, here are these patches.
Borislav, if you're okay with this (ab)use of the cpufeatures stuff
and if they survive review, I'd be okay with them joining your
series or going straight into tip:x86/asm.
Andy Lutomirski (2):
x86/nmi/64: Giant debugging hack
x86/entry/32: Intr
It no longer has any users.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/asm-offsets.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 84a7524b202c..5c042466f274 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86
x86_64 has very clean espfix handling on paravirt: espfix64 is set
up in native_iret, so paravirt systems that override iret bypass
espfix64 automatically. This is robust and straightforward.
x86_32 is messier. espfix is set up before the IRET paravirt patch
point, so it can't be directly condit
flight 84496 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84496/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 3 host-install(3) broken in 83951 REGR. vs. 66399
build-amd64-rumpuserxen
On Mon, Feb 29, 2016 at 03:10:48PM -0600, 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 w
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:
On 2/22/16 11:06 AM, Ian Jackson wrote:
> Doug Goldstein
flight 84578 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84578/
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 Mon, Feb 29, 2016 at 06:14:21AM -0600, Doug Goldstein wrote:
> No real advantage to keeping these separate. The use case of this from
> Linux is when the platform or target board has support for something but
> the user wants to be given the option to disable it.
>
> Signed-off-by: Doug Goldste
On Mon, Feb 29, 2016 at 03:39:36PM -0500, Konrad Rzeszutek Wilk wrote:
> Couple of updates:
> - Add an macro to make it easier to use the vector callback.
>
> - Fix the odditity in Xen internal usage of an enum which offset
>by one compared to the #defines. Make it the same.
>
> - This als
Couple of updates:
- Add an macro to make it easier to use the vector callback.
- Fix the odditity in Xen internal usage of an enum which offset
by one compared to the #defines. Make it the same.
- This also clears up the printing of the Callback in the
irq_dump() to match up with the #d
From: Shannon Zhao
Implement __acpi_map_table function for ARM. Move FIX_ACPI_PAGES to
common place and rename it to NUM_FIXMAP_ACPI_PAGES.
Cc: Jan Beulich
Signed-off-by: Shannon Zhao
---
v7: fix coding style
---
xen/arch/arm/Makefile| 1 +
xen/arch/arm/acpi/Makefile | 1 +
xen/ar
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 a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 150d727..9778947 10
This run is configured for baseline tests only.
flight 44196 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44196/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1
flight 84472 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
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 commit message
>> > ---
>> > xen/arch/arm/domain_build.c | 2
On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote:
> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> > This ports built-in firmware to use linker tables,
> > this replaces the custom section solution with a
> > generic solution.
> >
> > This also demos the use of the .r
flight 84489 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On 02/29/2016 10:29 AM, Olaf Hering wrote:
On Mon, Feb 29, Konrad Rzeszutek Wilk wrote:
On Mon, Feb 29, 2016 at 11:28:49AM +0100, Olaf Hering wrote:
Would this change be the correct fix?
.. A fix for what issue?
mmap returns some pointer, but appearently that memory can not be used.
https:/
On Mon, Feb 29, 2016 at 05:29:54AM -0700, Jan Beulich wrote:
> >>> On 29.02.16 at 13:23, wrote:
> > On Tue, Feb 23, 2016 at 02:31:30PM +, Wei Liu wrote:
> >> On Mon, Feb 22, 2016 at 04:28:19AM -0700, Jan Beulich wrote:
> >> > >>> On 19.02.16 at 17:05, wrote:
> >> > > On Wed, Feb 17, 2016 at 0
flight 84556 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/84556/
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 2/22/16 1:14 PM, Doug Goldstein wrote:
> On 2/22/16 10:22 AM, Ian Jackson wrote:
>> Doug Goldstein writes ("[PATCH v2 3/4] m4/python: fix checks for Python
>> library support"):
>>> AC_CHECK_LIB() was running gcc -Llib -lm -lutils conftest.c which on
>>> platforms that do as needed operations b
> > 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 environment using PARSEC Benchmark [1].
> >>
> >> In virtualiztion environment, we
On Mon, Feb 29, 2016 at 11:06 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Feb 26, 2016 at 12:02:50AM -0500, Meng Xu wrote:
>> Hi,
>>
>
> 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 envir
On 26/02/16 12:33, Ian Jackson wrote:
> George Dunlap writes ("[PATCH 7/8] tools/xenalyze: Fix multiple instances of
> *HYPERCALL_MAX"):
>> We HYPERCALL_MAX defined as the maximum enumerated hypercall, and we
> ^ missing word `have' ?
>
>> have PV_HYPERCALL_MAX defined as some other number (p
Dear all,
I have started using Xen recently, and faced a problem
about my internet connection.
I followed the instructions on this link
to setup my network but since then I can not connect to the internet.
I
really do not know what is the problem. The routing seems fine and the
xenbr0 finds th
On Sun, 28 Feb 2016, Shannon Zhao wrote:
> From: Naresh Bhat
>
> Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Shannon Zhao
> ---
> V4: add comments to explain why efi_enabled = 1 needs
> ---
> xen/arch/arm/Kconfig
EXPORT_SYMBOL_GPL is unused in the source tree so just remove it. If
something gets imported that needs it, it can be added back then.
Signed-off-by: Doug Goldstein
---
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
CC: Tim Deegan
---
xen/Makefile | 2 +-
xen/include/xen/config.
> -Original Message-
[snip]
> > > I was casting my mind back to incompatibilities that crept in with
> persistent grants. TBH I haven't used blkback much since then; I tend to use
> qemu qdisk as my backend these days.
> >
> > FWIW, QEMU Qdisk also has persistent grants support... and was
>
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 ...
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 2/23/16 2:57 AM, Li, Liang Z wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Monday, January 11, 2016 5:59 PM
>> To: Wei Liu; Li, Liang Z
>> Cc: ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
>> ian.jack...@eu.citrix.com; xen-devel@lists.xen.org; jbeul...@su
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 bringing it to my attention.
I propose this build fix:
77fec3a tools/console: correct make dependencies for _paths.h
On Sun, 28 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Store the event-channel interrupt number and flag in HVM parameter
> HVM_PARAM_CALLBACK_IRQ. Then Dom0 could get it through hypercall
> HVMOP_get_param.
>
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
> v4: al
On Sun, 28 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new dilivery type:
^ "delivery", also in the subject line
> val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
> To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
> bit 1 stands the in
>>> On 29.02.16 at 17:56, wrote:
> On Tue, Feb 23, 2016 at 04:22:35AM -0700, Jan Beulich wrote:
>> Patches 1 and 2 are meant to go in. Patch 3 is a prerequisite to patch
>> 4 and may go in as well, but patch 4 is RFC because with the Pericom
>> board I have MSI doesn't appear to function. Since it
On Sun, 28 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Firstly it permits full MMIO capabilities for Dom0. Then deny MMIO
> access of Xen used devices, such as UART, SMMU. Currently, it only
> denies the MMIO access of UART and for other Xen used devices it could
> be added later when
>>> On 25.02.16 at 15:56, wrote:
> @@ -127,22 +124,29 @@ static void seabios_setup_e820(void)
> struct e820entry *e820 = scratch_alloc(sizeof(struct e820entry)*16, 0);
> info->e820 = (uint32_t)e820;
>
> +BUG_ON(seabios_config.bios_address == 0);
I think this is too lax: Surely thi
On Sun, 28 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Interrupt information is described in DSDT and is not available at the
> time of booting. Check if the interrupt is permitted to access and set
> the interrupt type, route it to guest dynamically only for SPI
> and Dom0.
>
> Signe
>>> On 25.02.16 at 15:56, wrote:
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -303,6 +303,15 @@ int main(void)
>
> smp_initialise();
>
> +/* Check that tests does not use memory where modules are stored */
> +BUG_ON( ((uint32_t)hvm
On 26/02/16 12:30, Ian Jackson wrote:
> George Dunlap writes ("[PATCH 6/8] tools/xenalyze: Fix off-by-one in MAX_CPUS
> range checks"):
>> Skip action / throw error if cpu/vcpu >= MAX_CPUS rather than >.
>>
>> Also add an assertion to vcpu_find, to make future errors of this kind
>> not out-of-bo
>>> On 25.02.16 at 15:56, wrote:
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -254,10 +254,32 @@ static void acpi_enable_sci(void)
> BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
> }
>
> +const struct hvm_modlist_entry *get_module_entry(
> +
On Tue, Feb 23, 2016 at 04:22:35AM -0700, Jan Beulich wrote:
> Patches 1 and 2 are meant to go in. Patch 3 is a prerequisite to patch
> 4 and may go in as well, but patch 4 is RFC because with the Pericom
> board I have MSI doesn't appear to function. Since it also does not
> work in baremetal Linu
On Mon, Feb 29, 2016 at 04:35:36PM +0100, Roger Pau Monné wrote:
> El 29/2/16 a les 16:28, Paul Durrant ha escrit:
> >> -Original Message-
> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> >> Sent: 29 February 2016 14:56
> >> To: Paul Durrant
> >> Cc: Bob Liu; xen-devel@lis
>>> On 29.02.16 at 17:37, wrote:
On 25.02.16 at 15:56, wrote:
>> @@ -258,6 +263,7 @@ int main(void)
>> memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
>>
>> printf("HVM Loader\n");
>> +BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE);
>
> Wai
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
wrote:
> This series enables using hotplug
>>> On 29.02.16 at 17:20, wrote:
> El 29/2/16 a les 13:14, Jan Beulich ha escrit:
> On 29.02.16 at 11:57, wrote:
>>> El 29/2/16 a les 10:31, Jan Beulich ha escrit:
>>> On 26.02.16 at 18:02, wrote:
>>> -/* Space for the symbol and string tables. */
>>> +/* Space for the sy
>>> On 25.02.16 at 15:56, wrote:
> --- /dev/null
> +++ b/tools/firmware/hvmloader/hvm_start_info.h
> @@ -0,0 +1,32 @@
> +#ifndef __HVM_START_INFO_H__
> +#define __HVM_START_INFO_H__
> +
> +/* C representation of the x86/HVM start info layout.
> + *
> + * The canonical definition of this layout res
On Fri, Feb 26, 2016 at 12:02:50AM -0500, Meng Xu wrote:
> Hi,
>
Hey!
CC-ing Elena.
> We are measuring the execution time between native machine environment
> and xen virtualization environment using PARSEC Benchmark [1].
>
> In virtualiztion environment, we run a domU with three VCPUs, each o
>>> On 25.02.16 at 15:56, wrote:
> @@ -42,12 +42,19 @@ dsdt_%cpu.asl: dsdt.asl mk_dsdt
> awk 'NR > 1 {print s} {s=$$0}' $< > $@
> ./mk_dsdt --debug=$(debug) --maxcpu $* >> $@
>
> -$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
> +$(filter dsdt_%cpu.c,$(C_SRC)): %.c: iasl %.asl
Would
Ian Jackson writes ("Re: [RFC PATCH] xen-block: introduces extra request to
pass-through SCSI commands"):
> [stuff suggesting use of PVSCSI instead]
For the avoidance of doubt:
1. Thanks very much for bringing this proposal to us at the concept
stage. It is much easier to discuss these matters
On Mon, Feb 29, 2016 at 04:49:04PM +0100, Juergen Gross wrote:
> On 29/02/16 16:43, Daniel Kiper wrote:
> > On Mon, Feb 29, 2016 at 09:27:42AM +0100, Juergen Gross wrote:
> >> On 26/02/16 16:41, Daniel Kiper wrote:
> >>> On Fri, Feb 26, 2016 at 03:28:21PM +0100, Juergen Gross wrote:
> On 26/02
On Fri, Feb 26, 2016 at 12:34:56PM +, Ian Jackson wrote:
> George Dunlap writes ("[PATCH 8/8] tools/xenalyze: Actually handle case where
> number of ipi vectors exceeds static max"):
> > find_vec() is supposed to find the vector in the list if it exists,
> > choose an empty slot if it doesn't
On Fri, Feb 26, 2016 at 12:23:15PM +, Ian Jackson wrote:
> George Dunlap writes ("[PATCH 2/8] tools/xenalyze: Avoid redundant check"):
> > Coverity notices that if !head is true, that !N can never be true.
> >
> > Don't bother checking N, since we know it has to be at least one.
> >
> > CID 1
On Fri, Feb 26, 2016 at 12:29:02PM +, Ian Jackson wrote:
> George Dunlap writes ("[PATCH 5/8] tools/xenalyze: Fix check for error return
> value"):
> > fdopen returns NULL on failure, not a negative integer.
> >
> > CID 1306863
> > CID 1306858
> >
> > Signed-off-by: George Dunlap
> > ---
>
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 for xen.git tree. Please reply for items you
> woulk like to see in 4.7 so that people
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 just dup2'd fds. For this to happen
> > std{in,out,err} would have needed to be c
1 - 100 of 204 matches
Mail list logo
