>>> On 31.03.17 at 20:15, wrote:
> On Fri, 31 Mar 2017, Jan Beulich wrote:
>> The other one remains, though: As indicated before, only security patches
>> should be pushed to stable branches at about the same time as to
>> master's staging; everything else should please wait until the patch
>> has
>>> On 03.04.17 at 00:44, wrote:
> branch xen-4.6-testing
> xenbranch xen-4.6-testing
> job test-xtf-amd64-amd64-5
> testid xtf-run
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 02 April 2017 13:24
> To: xen-devel@lists.xen.org
> Cc: zhiyuan...@intel.com; Paul Durrant ; Ian
> Jackson ; Wei Liu
> Subject: [PATCH v10 3/6] x86/ioreq server: Add device model wrappers for
> new DMOP
>
>
>>> On 31.03.17 at 21:15, wrote:
> Introduce a C99 headers check, for non-ANSI compliant headers: 9pfs.h
> and pvcalls.h.
>
> In addition to the usual -include stdint.h, also add -include string.h
> to the C99 check to get the declaration of memcpy and size_t.
>
> For the same reason, also add -
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 02 April 2017 13:24
> To: xen-devel@lists.xen.org
> Cc: zhiyuan...@intel.com; Paul Durrant ; Jan
> Beulich ; Andrew Cooper
> ; George Dunlap
>
> Subject: [PATCH v10 6/6] x86/ioreq server: Synchronously reset
>>> On 31.03.17 at 21:50, wrote:
> The function hvm_translate_linear_addr() translates a virtual address to a
> linear address, not a linear address to a physical address. Correct its
> name.
>
> Both hvm_translate_virtual_addr() and hvmemul_virtual_to_linear() return a
> linear address, not a
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 31 March 2017 20:51
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Tim (Xen.org) ; Paul Durrant
> ; Julien Grall
> Subject: [PATCH for 4.9 1/6] x86/hvm: Correct some address space
> terminology
>
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 31 March 2017 20:51
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Tim
> (Xen.org) ; George Dunlap ; Jun
> Nakajima ; Kevin Tian ;
> Boris Ostrovsky ; Suravee Suthikulpanit
> ; Julie
>>> On 31.03.17 at 21:50, wrote:
> @@ -1154,13 +1154,13 @@ static void virtual_vmentry(struct cpu_user_regs
> *regs)
> /*
> * EFER handling:
> * hvm_set_efer won't work if CR0.PG = 1, so we change the value
> - * directly to make hvm_long_mode_enabled(v) work in L2.
> + *
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 31 March 2017 20:51
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Tim
> (Xen.org) ; Julien Grall
> Subject: [PATCH for 4.9 3/6] x86/hvm: Fix segmentation logic for system
> segment
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 31 March 2017 20:51
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Tim
> (Xen.org) ; Julien Grall
> Subject: [PATCH for 4.9 5/6] x86/emul: Drop swint_emulate infrastructure
>
> Wit
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 31 March 2017 20:51
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Paul Durrant ; Tim
> (Xen.org) ; Julien Grall
> Subject: [PATCH for 4.9 6/6] x86/emul: Require callers to provide LMA in the
> em
On Wed, Mar 29, 2017 at 11:27:49AM +0100, Andrew Cooper wrote:
> On 27/03/17 10:10, Wei Liu wrote:
> > We will later split out PV specific code to pv/mm.c.
> >
> > No functional change.
> >
> > Signed-off-by: Wei Liu
>
> Please could you take the time to correctly mfn_t/gfn_t the calls.
> Having
branch xen-4.6-testing
xenbranch xen-4.6-testing
job test-xtf-amd64-amd64-1
testid xtf-fep
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.
On 31/03/17 20:50, Andrew Cooper wrote:
> hvm_long_mode_enabled() tests for EFER.LMA, which is specifically different to
> EFER.LME.
>
> Rename it to match its behaviour, and have it strictly return a boolean value
> (although all its callers already use it in implicitly-boolean contexts, so no
>
Hi,
On 31/03/17 23:59, Stefano Stabellini wrote:
> On Fri, 31 Mar 2017, Andre Przywara wrote:
>> The ARM GICv3 provides a new kind of interrupt called LPIs.
>> The pending bits and the configuration data (priority, enable bits) for
>> those LPIs are stored in tables in normal memory, which softwar
flight 71143 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71143/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-sid-netboot-pygrub 10 capture-logs(10) broken blocked in
71108
test-amd64-i
>>> On 31.03.17 at 21:50, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2374,13 +2374,27 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
> return X86EMUL_OKAY;
> }
>
> +enum hvm_segmentation_mode hvm_seg_mode(
> +const struct vcpu *v, enum x86_seg
Hi Stefano,
On 31/03/17 23:33, Stefano Stabellini wrote:
On Fri, 31 Mar 2017, Julien Grall wrote:
Hi Stefano,
On 03/30/2017 11:35 PM, Stefano Stabellini wrote:
parse_vwfi runs after init_traps on cpu0, potentially resulting in the
wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so
On Mon, Apr 03, 2017 at 09:13:20AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> > Sent: 02 April 2017 13:24
> > To: xen-devel@lists.xen.org
> > Cc: zhiyuan...@intel.com; Paul Durrant ; Ian
> > Jackson ; Wei Liu
> > Subject: [PAT
>>> On 31.03.17 at 21:50, wrote:
> +static void svm_emul_swint_injection(struct x86_event *event)
> +{
> +struct vcpu *curr = current;
> +struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
> +struct cpu_user_regs *regs = guest_cpu_user_regs();
All three look like they can be const.
>>> On 31.03.17 at 21:50, wrote:
> With the SVM injection logic capable of doing its own emulation, there is no
> need for this hardware-specific assistance in the common emulator.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one remark below.
> ---
> tools/fuzz/x86_instruc
Modify the domain structure to to make console specific fields as an array
indexed
by the console type. Two console types are defined - PV and VCON.
Signed-off-by: Bhupinder Thakur
---
tools/console/daemon/io.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
dif
PL011 emulation for guests in Xen
===
This feature allows the Xen guests to map their console to a SBSA compliant
pl011 UART as specified in ARM Service Base System architecture, Appendix B.
See
https://static.docs.arm.com/den0029/a/Server_Base_System_Architectur
An option is provided in libxl to enable/disable pl011 emulation while
creating a guest domain.
Signed-off-by: Bhupinder Thakur
---
tools/libxl/libxl_create.c | 12
tools/libxl/libxl_internal.h | 5 +
tools/libxl/libxl_types.idl | 2 ++
tools/libxl/xl_cmdimpl.c | 4 +++
Add emulation code to emulate read/write access to pl011 registers
and pl011 interrupts:
- Emulate DR read/write by reading and writing from/to the IN
and OUT ring buffers and raising an event to the backend when
there is data in the OUT ring buffer and injecting an interrupt
1. Add two new HVM param handlers for:
- Allocate a new event channel for sending/receiving events to/from Xen.
- Map the PFN allocted by the toolstack to be used as IN/OUT ring buffers.
2. Add validation to disallow get/set of these HVM params from guest
domain.
Xen will communicate with
1. Allocate a new pfn and pass on to Xen using a hvm call.
2. Change in xc_hvm_param_deprecated_check () to allow new vpl011 HVM params,
which are reusing some deprecated x86 HVM params.
Signed-off-by: Bhupinder Thakur
---
tools/libxc/include/xc_dom.h | 3 +++
tools/libxc/xc_dom_arm.c | 7 +
Vpl011 emulation is enabled for a guest domain in Xen only when it is
enabled through an option in libxl provided by the user through
guest configuration.
The pl011 enable/disable knob in libxl is introduced in the following
patch:
xen/arm: vpl011: Provide a knob in libxl to enable/disable pl011
e
Xenconsole supports only PV console currently. To get access to emulated pl011
uart another backend console is required.
This patch modifies different data structures and APIs used
in xenconsole to support two console types: PV and VCON (virtual console).
Change summary:
1. Modify the domain str
Add two new parameters to the xen store:
- newly allocated PFN to be used as IN/OUT ring buffer by xenconsoled
- a new event channel read from Xen using a hvm call to be used by
xenconsoled
Signed-off-by: Bhupinder Thakur
---
tools/libxl/libxl.c | 10 ++
tools/libxl/libxl_do
The SBSA uart node format is as specified in
Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:
ARM SBSA defined generic UART
--
This UART uses a subset of the PL011 registers and consequently lives
in the PL011 driver. It's baudrate and other c
Add a new console type VCON to connect to the virtual console.
Signed-off-by: Bhupinder Thakur
---
tools/console/client/main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index 99f..03b6fb1 100644
--- a/tools/console/cli
flight 107134 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-destroyfail REGR. vs. 106819
test-xtf-amd64-
Hi Vijay,
On 28/03/17 13:35, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
On ARM64, virt_to_mfn uses the hardware for address
translation. So if the virtual address is not mapped translation
fault is raised. On ARM64, DIRECTMAP_VIRT region is direct mapped.
You are stating obvious thin
>>> On 31.03.17 at 21:50, wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5410,6 +5410,7 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long
> addr,
> .ctxt = {
> .regs = regs,
> .vendor = d->arch.cpuid->x86_vendor,
> +.lma = tru
Hi Ian,
On 30/03/17 15:40, Ian Jackson wrote:
Hi. Christian Lindig of Citrix has been looking into our ARM64 ocaml
build problem. See attached mail from him.
(NB: xen-devel added to CC list.)
Christian writes:
My short-term strategy would be to exclude the ocaml xenstored on
architectures t
On 03/04/17 09:24, Jan Beulich wrote:
On 31.03.17 at 21:50, wrote:
>> The function hvm_translate_linear_addr() translates a virtual address to a
>> linear address, not a linear address to a physical address. Correct its
>> name.
>>
>> Both hvm_translate_virtual_addr() and hvmemul_virtual_to
>>> On 01.04.17 at 18:56, wrote:
> On 03/31/2017 06:04 PM, Jan Beulich wrote:
> On 31.03.17 at 17:01, wrote:
>>> On 03/31/2017 05:46 PM, Jan Beulich wrote:
>>> On 31.03.17 at 11:56, wrote:
> On 03/31/2017 10:34 AM, Jan Beulich wrote:
> On 31.03.17 at 08:17, wrote:
>>> On
>>> On 03.04.17 at 12:19, wrote:
> On 03/04/17 09:24, Jan Beulich wrote:
> On 31.03.17 at 21:50, wrote:
>>> --- a/xen/arch/x86/mm/shadow/common.c
>>> +++ b/xen/arch/x86/mm/shadow/common.c
>>> @@ -136,13 +136,13 @@ static struct segment_register *hvm_get_seg_reg(
>>> return seg_reg;
>>>
>>> On 31.03.17 at 16:46, wrote:
> This patch masks .AnyThread bits in IA32_FIXED_CTR_CTRL MSR for all
> versions of Intel Arhcitectural Performance Monitoring. Note that
> .AnyThread bit (21) is already masked in IA32_PERFEVTSELx MSRs since
> hyperthreading is not exposed to guests and Intel SDM
Hi Stefano,
Stefano Stabellini writes:
> On Fri, 31 Mar 2017, Punit Agrawal wrote:
>> When toolstack requests flushing the caches, flush_page_to_ram() is
>> called for each page of the requested domain. This needs to unnecessary
>> icache invalidation operations.
>>
>> Let's take the responsibi
flight 107143 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-buildfail REGR. vs. 106829
Tests which did not suc
When booting using ACPI, not all MMIOs can be discovered by parsing the
static tables or the UEFI memory map. A lot of them will be described in
the DSDT. However, Xen does not have an AML parser which requires us to
find a different approach.
During the first discussions on supporting ACPI (see d
Hi,
On 22/03/17 15:59, Julien Grall wrote:
> Hi Andre,
>
> On 16/03/17 11:20, Andre Przywara wrote:
>> To be able to easily send commands to the ITS, create the respective
>> wrapper functions, which take care of the ring buffer.
>> The first two commands we implement provide methods to map a col
Hi Ishani, (+Doug, +Andy)
not that the deadline as been extended to April 13. I am also CC'ing Andy
Cooper as Doug has not responded.
The challenge that we will have is to satisfy the small task requirement while
also making the task sensible in the context of the project. Now we do have
some
Hi Stefano,
On 31/03/17 21:24, Stefano Stabellini wrote:
On Fri, 31 Mar 2017, Julien Grall wrote:
On 30/03/17 00:47, Stefano Stabellini wrote:
On Fri, 3 Mar 2017, Julien Grall wrote:
What you described is not a data corruption to me.
No, it is not, thanks to the previous two patches. The co
On Mon, Mar 27, 2017 at 8:28 PM, Gémes Géza wrote:
> Hi,
>
> Currently the xen build system has optional support for building a minios
> (+needed libraries and tools) based stubdom.
>
> What is your opinion about moving support for building this into raisin and
> once that is stable drop support i
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c| 2 --
xen/include/asm-x86/mm.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 823aba01a8..e1ce77b9ac 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/m
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/mm.c | 68 ++
xen/arch/x86/x86_64/mm.c | 70
2 files changed, 68 insertions(+), 70 deletions(-)
diff --git a/xen/arch/x86/pv/mm.c b/x
PG_external requires hardware support so the code guarded by that is HVM
only.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/Makefile | 1 +
xen/arch/x86/hvm/mm.c | 85 +++
xen/arch/x86/mm.c | 49 --
xen/i
Define several _* and *_x macros for better grep-ability. This also
helps indexing tool like GNU Global.
No functional change.
Signed-off-by: Wei Liu
---
xen/include/xen/mm.h | 12
1 file changed, 12 insertions(+)
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 88de
Hi Andre,
On 03/04/17 11:58, Andre Przywara wrote:
+#define BUFPTR_MASK GENMASK(19, 5)
+static int its_send_command(struct host_its *hw_its, const void
*its_cmd)
+{
+s_time_t deadline = NOW() + MILLISECS(1);
It would be nice to explain where does this value comes from.
We will later split out PV specific code to pv/mm.c.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index be4e308608..2137f2b6f8 100644
--- a/xen/arch/
This serie split PV and HVM specific code from x86/mm.c and x86_64/mm.c.
A lot more code is moved in this version, given that I am now able to move
do_mmuext_op.
Wei.
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Tim Deegan
Cc: George Dunlap
Wei Liu (8):
mm: provide more grep fodders
x86/mm: ca
We will later split out PV specific code to pv/mm.c.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 2137f2b6f8..823aba01a8 100644
--- a/xen/arc
It's only needed there. Also make it static and delete the declaration
from mm.h.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/pv/mm.c | 86 +++
xen/arch/x86/x86_64/mm.c | 87
xen/i
On 03/04/17 12:22, Wei Liu wrote:
> Define several _* and *_x macros for better grep-ability. This also
> helps indexing tool like GNU Global.
>
> No functional change.
>
> Signed-off-by: Wei Liu
"fodder" is uncountable, so the patch title should be "provide more grep
fodder".
With that fixed:
If ocaml.m4 didn't find ocamlopt, disable all the ocaml builds.
Currently our Makefiles do not work properly when the native code
compiler (`ocamlopt') is not available. In principle this should be
fixed to fall back to bytecode, but this is not a task for this stage
of the Xen 4.9 release.
With
On Mon, Apr 03, 2017 at 12:34:13PM +0100, Ian Jackson wrote:
> If ocaml.m4 didn't find ocamlopt, disable all the ocaml builds.
>
> Currently our Makefiles do not work properly when the native code
> compiler (`ocamlopt') is not available. In principle this should be
> fixed to fall back to byteco
>>> On 31.03.17 at 17:42, wrote:
The title needs improvement - it doesn't really reflect what the
patch does.
> Add name=value parsing options for com1 and com2 to add flexibility
> in setting register values for MMIO UART devices.
>
> Maintain backward compatibility with previous positional pa
On Mon, Apr 03, 2017 at 12:17:08PM +0100, George Dunlap wrote:
> On Mon, Mar 27, 2017 at 8:28 PM, Gémes Géza wrote:
> > Hi,
> >
> > Currently the xen build system has optional support for building a minios
> > (+needed libraries and tools) based stubdom.
> >
> > What is your opinion about moving s
Hello,
Thanks for the reply. I started with looking into format of Xen Hypervisor
files and creating a clang format file for the same. However, given the present
implementation of clang-format, it is not possible to incorporate fine-grained
custom coding format requirements. For example, althou
On 31/03/17 16:38, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 31, 2017 at 04:46:27AM -0600, Jan Beulich wrote:
> On 31.03.17 at 10:07, wrote:
>>> On Fri, Mar 31, 2017 at 05:05:44AM +, Tian, Kevin wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, March 27, 2017 4
On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> For kdump to work correctly it needs the physical address of
> vmcoreinfo_note. When running as dom0 this means the virtual address
> has to be translated to the related machine address.
>
> paddr_vmcoreinfo_note() is meant to do the
Hi all,
A quick reminder, the code freeze for Xen 4.9 will be this Friday (7th
April).
I am expecting to cut an RC beginning of next week.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Mon, Apr 03, 2017 at 01:54:43PM +0100, Julien Grall wrote:
> Hi all,
>
> A quick reminder, the code freeze for Xen 4.9 will be this Friday (7th
> April).
>
> I am expecting to cut an RC beginning of next week.
>
I suppose everything should be committed by Friday?
Wei.
> Cheers,
>
> --
>
Hi Wei,
On 03/04/17 13:56, Wei Liu wrote:
On Mon, Apr 03, 2017 at 01:54:43PM +0100, Julien Grall wrote:
Hi all,
A quick reminder, the code freeze for Xen 4.9 will be this Friday (7th
April).
I am expecting to cut an RC beginning of next week.
I suppose everything should be committed by Fri
Hi Andre,
On 31/03/17 19:05, Andre Przywara wrote:
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
new file mode 100644
index 000..77f6009
--- /dev/null
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -0,0 +1,209 @@
[...]
+#include
+#include
+#include
+#include
+#include
+#inc
Juergen Gross writes ("[PATCH v3 0/4] xenstore: rework of transaction
handling"):
> Rework the transaction handling of xenstored to no longer raise
> conflicts so often.
>
> This series has been sent for pre-review to some reviewers before as the
> series is related to XSA 206 which has been disc
Juergen Gross writes ("[PATCH 0/2] xensore: fixing two bugs"):
> Two small patches to fix bugs: one error path correction (setting
> correct error code for caller) and add some missing checks for
> allocation failures.
>
> Juergen Gross (2):
> xenstore: set correct error code when violating quot
flight 107138 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107138/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 9 debian-di-install fail in 107103 pass in 107138
test-amd64-i386-rumprun-i386 16
On 03/04/17 14:53, Julien Grall wrote:
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index bd0883a..9261e06 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -5,11 +5,14 @@
/*
* Create a contiguous bitmask starting at bit position @l and ending at
*
> +static void svm_emul_swint_injection(struct x86_event *event)
> +{
> +struct vcpu *curr = current;
> +struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
> +struct cpu_user_regs *regs = guest_cpu_user_regs();
> +
> +unsigned int trap = event->vector, type = event->type;
> +u
Hi,
On 24/03/17 12:03, Julien Grall wrote:
> Hi Andre,
>
> On 03/16/2017 11:20 AM, Andre Przywara wrote:
>> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
>> number to get this IRQ injected.
>> Iterate our two-level LPI table to find this information quickly when
>> the hos
On 03/04/17 09:40, Wei Liu wrote:
> On Wed, Mar 29, 2017 at 11:27:49AM +0100, Andrew Cooper wrote:
>> On 27/03/17 10:10, Wei Liu wrote:
>>> We will later split out PV specific code to pv/mm.c.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Wei Liu
>> Please could you take the time to correct
>>> On 02.04.17 at 14:24, wrote:
> Previously, p2m_ioreq_server is used to write-protect guest ram
> pages, which are tracked with ioreq server's rangeset. However,
> number of ram pages to be tracked may exceed the upper limit of
> rangeset.
>
> Now, a new DMOP - XEN_DMOP_map_mem_type_to_ioreq_s
On 03/04/17 10:13, Jan Beulich wrote:
On 31.03.17 at 21:50, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2374,13 +2374,27 @@ int hvm_set_cr4(unsigned long value, bool_t
>> may_defer)
>> return X86EMUL_OKAY;
>> }
>>
>> +enum hvm_segmentation_mode hvm_s
>>> On 02.04.17 at 14:24, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -317,6 +317,15 @@ int p2m_set_ioreq_server(struct domain *d,
> if ( p2m->ioreq.server != NULL )
> goto out;
>
> +/*
> + * It is possible that an ioreq server ha
* Juergen Gross wrote:
> > So my suggestion would be: could you delay 75cd32d6093e for a week, and
> > then
> > merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on
> > the
> > first day of the merge window so there shouldn't be any ordering problems.
>
> Okay, that's
>>> On 03.04.17 at 16:36, wrote:
On 02.04.17 at 14:24, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -317,6 +317,15 @@ int p2m_set_ioreq_server(struct domain *d,
>> if ( p2m->ioreq.server != NULL )
>> goto out;
>>
>> +/*
>> +
On 03/04/17 16:38, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>>> So my suggestion would be: could you delay 75cd32d6093e for a week, and
>>> then
>>> merge it on top of a pulled in tip:x86/mm? I'll send that tree to Linus on
>>> the
>>> first day of the merge window so there shouldn't
Wei Liu writes ("Re: [PATCH] tools: ocaml: In configure, check for ocamlopt"):
> On Mon, Apr 03, 2017 at 12:34:13PM +0100, Ian Jackson wrote:
> > CC: Julien Grall
> > CC: Christian Lindig
> > CC: Jonathan Ludlam
> > CC: David Scott
> > CC: Wei Liu
> > Tested-by: Ian Jackson
> > Signed-off-by:
Ian Jackson writes ("Re: [PATCH] tools: ocaml: In configure, check for
ocamlopt"):
> Wei Liu writes ("Re: [PATCH] tools: ocaml: In configure, check for ocamlopt"):
> > On Mon, Apr 03, 2017 at 12:34:13PM +0100, Ian Jackson wrote:
> > > CC: Julien Grall
> > > CC: Christian Lindig
> > > CC: Jonatha
>>> On 03.04.17 at 16:27, wrote:
> On 03/04/17 10:13, Jan Beulich wrote:
> On 31.03.17 at 21:50, wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -2374,13 +2374,27 @@ int hvm_set_cr4(unsigned long value, bool_t
> may_defer)
>>> return X86EMUL_OKAY;
>>> }
>>> On 02.04.17 at 14:24, wrote:
> After an ioreq server has unmapped, the remaining p2m_ioreq_server
> entries need to be reset back to p2m_ram_rw. This patch does this
> synchronously by iterating the p2m table.
>
> The synchronous resetting is necessary because we need to guarantee
> the p2m t
flight 107142 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107142/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
> On 29 Mar 2017, at 05:51, Juergen Gross wrote:
>
> On 28/03/17 21:33, Mike Wright wrote:
>> On 03/28/2017 12:11 PM, Mohsen wrote:
>>> I'm using LibreOffice 4.3.3.2 on Debian amd64 and this version not
>>> have MediaWiki export function!!
>>
>> There was a deb for the libreoffice extension
>>
Hi Andre,
On 31/03/17 19:05, Andre Przywara wrote:
Each ITS maps a pair of a DeviceID (for instance derived from a PCI
b/d/f triplet) and an EventID (the MSI payload or interrupt ID) to a
pair of LPI number and collection ID, which points to the target CPU.
This mapping is stored in the device a
Hi Stefano,
Thanks for Input. I was not able to spend enough time last couple of weeks
due to projects. I have received mail from Lars Kurt explaining submission
of draft proposal and possibility to work on micro tasks.
I have created a draft proposal from with your inputs and what i learnt
about
On 03/04/17 16:07, Jan Beulich wrote:
On 03.04.17 at 16:27, wrote:
>> On 03/04/17 10:13, Jan Beulich wrote:
>> On 31.03.17 at 21:50, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2374,13 +2374,27 @@ int hvm_set_cr4(unsigned long value, bool_t
>> may
>>> On 01.04.17 at 15:53, wrote:
I was about to ack this, but there are a few more things which bother
me.
> ---
> v10:
> - remove initialization for 'PSR_SOCKET_L3_CAT'.
> (suggested by Jan Beulich)
> - rename 'feat_ops' to 'feat_props'.
> (suggested by Jan Beulich)
> -
flight 107157 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107157/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
Hi Andre,
On 31/03/17 19:05, Andre Przywara wrote:
Instead of directly manipulating the tables in memory, an ITS driver
sends commands via a ring buffer in normal system memory to the ITS h/w
to create or alter the LPI mappings.
Allocate memory for that buffer and tell the ITS about it to be abl
>>> On 03.04.17 at 17:42, wrote:
> On 03/04/17 16:07, Jan Beulich wrote:
> On 03.04.17 at 16:27, wrote:
>>> On 03/04/17 10:13, Jan Beulich wrote:
>>> On 31.03.17 at 21:50, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2374,13 +2374,27 @@ int hvm_s
On Fri, Mar 31, 2017 at 09:16:53AM -0600, Jan Beulich wrote:
> >>> On 29.03.17 at 16:47, wrote:
> > Rearrange the fields of hvm_irq so that gsi_assert_count can be converted
> > into
> > a variable size array and add a new field to account the number of GSIs.
> >
> > Due to this changes the irq
Hi Ishani,
> On 3 Apr 2017, at 13:01, Ishani wrote:
>
> Thanks for the reply. I started with looking into format of Xen Hypervisor
> files and creating a clang format file for the same. However, given the
> present implementation of clang-format, it is not possible to incorporate
> fine-grain
Hi, all.
Playing with non-shared IOMMU in Xen on ARM I faced one interesting
thing. I found out that the superpages were shattered during domain
life cycle.
This is the result of mapping of foreign pages, ballooning memory,
even if domain maps Xen shared pages, etc.
I don't bother with the memory
On 03/04/17 17:24, Oleksandr Tyshchenko wrote:
> Hi, all.
>
> Playing with non-shared IOMMU in Xen on ARM I faced one interesting
> thing. I found out that the superpages were shattered during domain
> life cycle.
> This is the result of mapping of foreign pages, ballooning memory,
> even if domain
When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.
Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_page
1 - 100 of 211 matches
Mail list logo
