>>> On 26.01.17 at 18:28, wrote:
> The problem is that it is not exposed to Linux, but I can see it
> in FreeBSD [1] and the helper to convert error codes [2] there as well.
> Is there any reason these are not available in Linux?
Well, the header should eventually get added there (but see also
Ju
On 01/27/2017 10:01 AM, Jan Beulich wrote:
On 26.01.17 at 18:28, wrote:
The problem is that it is not exposed to Linux, but I can see it
in FreeBSD [1] and the helper to convert error codes [2] there as well.
Is there any reason these are not available in Linux?
Well, the header should eventua
BTW, what do you think about adding FB functionality into DISPLIF protocol?
Of course it will duplicate FB, but allow future extensions
On 01/27/2017 09:56 AM, Jan Beulich wrote:
On 26.01.17 at 19:39, wrote:
Does the below answer your question?
I think that's fine, once added to the actual
On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
> On 01/27/2017 09:46 AM, Juergen Gross wrote:
>> On 27/01/17 08:21, Oleksandr Andrushchenko wrote:
>>> On 01/27/2017 09:12 AM, Juergen Gross wrote:
Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront
>>> On 27.01.17 at 09:11, wrote:
> BTW, what do you think about adding FB functionality into DISPLIF protocol?
>
> Of course it will duplicate FB, but allow future extensions
I have no particular opinion here, other than my general dislike of
duplication / redundancy.
Jan
On 01/27/2017 10:14 AM, Juergen Gross wrote:
On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
On 01/27/2017 09:46 AM, Juergen Gross wrote:
On 27/01/17 08:21, Oleksandr Andrushchenko wrote:
On 01/27/2017 09:12 AM, Juergen Gross wrote:
Instead of using the default resolution of 800*600 for the
On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
> On 01/27/2017 10:14 AM, Juergen Gross wrote:
>> On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
>>> On 01/27/2017 09:46 AM, Juergen Gross wrote:
On 27/01/17 08:21, Oleksandr Andrushchenko wrote:
> On 01/27/2017 09:12 AM, Juergen Gross w
Hi George,
I didn't test official Renesas yocto layer for Lager board.
But general approach to bring-up xen-tools in Dom0 rootfs are follow:
1. clone meta-virtualization layer along with other layers
2. Append xen-base package into default package list (e.g.
core-image-minimal or weston-image-min
flight 104736 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 9 windows-install fail REGR. vs. 104358
Regressions whi
>>> On 27.01.17 at 05:47, wrote:
> flight 104728 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/104728/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debi
On 26/01/17 22:21, Peter Maydell wrote:
> On 26 January 2017 at 20:47, Peter Maydell wrote:
>> On 26 January 2017 at 19:36, Stefano Stabellini
>> wrote:
>>> It should be just a matter of replacing qdev_init_nofail with something
>>> that can fail. I couldn't find a regular qdev_init that can ret
>>> On 27.01.17 at 09:59, wrote:
> version targeted for testing:
> xen b29aed8b0355fe9f7d49faa9aef12b2f8f983c2c
> baseline version:
> xen e1cefedd80f9972854769bfc6e32e23b56cd0712
>
> Last test of basis 104358 2017-01-20 18:08:51 Z6 days
> Testing same si
On 24/01/17 22:47, Jim Fehlig wrote:
> On 01/23/2017 02:49 AM, Juergen Gross wrote:
>> The information given in the xl man page for the mem-max command is
>> rather brief. Expand it in order to let the reader understand what it
>> is really doing.
>>
>> As the related libxl function libxl_domain_se
On 26/01/17 19:12, Mohit Gambhir wrote:
> This patch fixes the following warning message seen when booting the
> kernel as Dom0 with Xen on Intel machines.
>
> [0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1]
>
> The code generating the warning in validate_apic_and_package_
flight 104742 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 9 debian-install fail REGR. vs. 104685
Regressions which are r
On 01/26/2017 04:37 AM, Paul Durrant wrote:
> The Xen HVM unplug protocol [1] specifies a mechanism to allow guests to
> request unplug of 'aux' disks (which is stated to mean all IDE disks,
> except the primary master). This patch adds support for that unplug request.
>
> NOTE: The semantics of
On 24/01/17 17:42, Roger Pau Monné wrote:
> Hello,
>
> The following commit:
>
> commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
> Author: Juergen Gross
> Date: Tue Nov 22 07:10:58 2016 +0100
>
> xen: create qdev for each backend device
>
> Prevents me from running QEMU on FreeBSD/Xen, the f
At 05:41 -0700 on 26 Jan (1485409318), Jan Beulich wrote:
> >>> On 19.01.17 at 18:29, wrote:
> > +/* Size of the VM86 TSS for virtual 8086 mode to use. */
> > +#define HVM_VM86_TSS_SIZE 128
>
> I continue to be puzzled by this value. Why 128? I think this really
> needs to be clarified in the c
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 January 2017 09:00
> To: Paul Durrant
> Cc: xen-devel ; osstest-
> ad...@xenproject.org
> Subject: Re: [Xen-devel] [xen-unstable test] 104728: regressions - FAIL
>
> >>> On 27.01.17 at 05:47, wrote:
> > flight
On Fri, Jan 27, 2017 at 10:37:51AM +0100, Juergen Gross wrote:
> On 24/01/17 22:47, Jim Fehlig wrote:
> > On 01/23/2017 02:49 AM, Juergen Gross wrote:
> >> The information given in the xl man page for the mem-max command is
> >> rather brief. Expand it in order to let the reader understand what it
On 23/01/17 16:43, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
>
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
>
>
The information given in the xl man page for the mem-max command is
rather brief. Expand it in order to let the reader understand what it
is really doing.
As the related libxl function libxl_domain_setmaxmem() isn't much
clearer add a comment to it explaining the desired semantics.
Signed-off-by:
XS_RESTRICT and the xenstore library function xs_restrict() have never
been usable in all configurations and there are no known users.
This functionality was thought to limit access rights of device models
to xenstore in order to avoid affecting other domains in case of a
security breech. Unfortun
On Fri, Jan 27, 2017 at 12:45:18PM +0100, Juergen Gross wrote:
> The information given in the xl man page for the mem-max command is
> rather brief. Expand it in order to let the reader understand what it
> is really doing.
>
> As the related libxl function libxl_domain_setmaxmem() isn't much
> cl
Hi,
I have done the changes for emulating pl011 in Xen. Currently, I have
verified the emulation code by manually reading/writing data to
/dev/ttyAMA0 which is the device file for pl011 device. The data is
flowing fine between xenconsoled and the guest domain.
As a next step, I wanted to use /dev
On 23/01/17 16:43, Ronald Rojas wrote:
> Create error type Errorxl for throwing proper xenlight
> errors.
>
> Update Ctx functions to throw Errorxl errors.
>
> Signed-off-by: Ronald Rojas
Everything here looks, good with a few nitpicks...
> ---
> tools/golang/xenlight/xenlight.go | 75
>
On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
> >>> On 19.01.17 at 18:29, wrote:
> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages;
> > static long __initdata dom0_min_nrpages;
> > static long __initdata dom0_max_nrpages = LONG_MAX;
> >
> > +/* Size of the VM86 TSS for v
On Fri, Jan 27, 2017 at 11:14:10AM +, Tim Deegan wrote:
> At 05:41 -0700 on 26 Jan (1485409318), Jan Beulich wrote:
> > >>> On 19.01.17 at 18:29, wrote:
> > > +/* Size of the VM86 TSS for virtual 8086 mode to use. */
> > > +#define HVM_VM86_TSS_SIZE 128
> >
> > I continue to be puzzled by t
On 27/01/17 11:14, Tim Deegan wrote:
> At 05:41 -0700 on 26 Jan (1485409318), Jan Beulich wrote:
> On 19.01.17 at 18:29, wrote:
>>> +/* Size of the VM86 TSS for virtual 8086 mode to use. */
>>> +#define HVM_VM86_TSS_SIZE 128
>> I continue to be puzzled by this value. Why 128? I think this re
From: Oleksandr Andrushchenko
Hi, all!
Please find the next version of the ABI for the PV sound
after addressing review comments.
Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr Andrushchenko (1):
xen/sndif: Add sound-device ABI
xen/include/public/io/sndif.h | 725 ++
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.
Note: depending on the use-case back
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intent
PFA pahole output
On 01/27/2017 03:08 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer de
PFA pahole output
On 01/27/2017 03:03 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
Please find the next version of the ABI for the PV sound
after addressing review comments.
Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr Andrushchenko (1):
xe
flight 104741 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104741/
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. 59254
test-armhf-armhf-xl
Hi,
At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
> On 27/01/17 11:14, Tim Deegan wrote:
> > But looking at it now, I'm not convinced of exactly how. The magic
> > bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
> > base address itself lives at offset 100. A ze
On 27/01/17 13:20, Tim Deegan wrote:
> Hi,
>
> At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
>> On 27/01/17 11:14, Tim Deegan wrote:
>>> But looking at it now, I'm not convinced of exactly how. The magic
>>> bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
>>> bas
Hi,
At 13:46 + on 27 Jan (1485524765), Andrew Cooper wrote:
> The actual behaviour can be determined by putting the TSS on a page
> boundary, making the previous frame non-readable via EPT, and seeing
> whether an EPT violation occurs.
Indeed. Or likewise with normal pagetables.
> > Yes, I
c/s 524a98c2ac5 "public / x86: introduce __HYPERCALL_dm_op" gave flask
permisisons for a stubdomain to use dmops, but omitted the case of a device
model running in dom0.
Signed-off-by: Andrew Cooper
---
CC: Paul Durrant
CC: Ian Jackson
CC: Wei Liu
CC: Daniel De Graaf
CC: Jan Beulich
---
too
flight 104764 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104764/
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
On Fri, Jan 27, 2017 at 02:16:58PM +, Andrew Cooper wrote:
> c/s 524a98c2ac5 "public / x86: introduce __HYPERCALL_dm_op" gave flask
> permisisons for a stubdomain to use dmops, but omitted the case of a device
> model running in dom0.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
_
On 27/01/17 14:01, Tim Deegan wrote:
> Hi,
>
> At 13:46 + on 27 Jan (1485524765), Andrew Cooper wrote:
>> The actual behaviour can be determined by putting the TSS on a page
>> boundary, making the previous frame non-readable via EPT, and seeing
>> whether an EPT violation occurs.
> Indeed. Or
On Fri, Jan 27, 2017 at 12:47:22PM +0100, Juergen Gross wrote:
> XS_RESTRICT and the xenstore library function xs_restrict() have never
> been usable in all configurations and there are no known users.
>
> This functionality was thought to limit access rights of device models
> to xenstore in orde
On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> When the toolstack modifies memory of a running ARM VM it may happen
> that the underlying memory of a current vCPU PC is changed. Without
> flushing the icache the vCPU may continue executing stale instructions.
>
Why is this not
On Thu, Jan 26, 2017 at 12:09:30PM +0100, Dario Faggioli wrote:
> On Thu, 2017-01-26 at 12:02 +0200, Oleksandr Andrushchenko wrote:
> > Hi, Konrad!
> >
> > First of all thank you very much for the valuable comments
> >
> > and your time!
> >
> > The number of changes (mostly in description) is g
On 25/01/17 18:33, Joao Martins wrote:
> This file defines an ABI shared between guest and hypervisor(s)
> (KVM, Xen) and as such there should be an correspondent entry in
> MAINTAINERS file. Notice that there's already a text notice at the
> top of the header file, hence this commit simply enforce
On Thu, Jan 26, 2017 at 06:33:11AM -0700, Jan Beulich wrote:
> >>> On 19.01.17 at 18:29, wrote:
> > --- a/xen/include/asm-x86/hvm/support.h
> > +++ b/xen/include/asm-x86/hvm/support.h
> > @@ -71,6 +71,8 @@ enum hvm_copy_result hvm_copy_to_guest_phys(
> > paddr_t paddr, void *buf, int size);
>
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 27 January 2017 14:33
> To: Andrew Cooper
> Cc: Xen-devel ; Paul Durrant
> ; Ian Jackson ; Wei Liu
> ; Daniel De Graaf ; Jan
> Beulich
> Subject: Re: [PATCH] xsm: Permit dom0 to use dmops
>
> On Fri, Jan 27, 2017 a
On Thu, Jan 26, 2017 at 03:35:46PM +, Roger Pau Monne wrote:
> This patch adds the headers and helpers for the FreeBSD gntdev, used in order
> to map grants from remote domains and to allocate grants on behalf of the
> current domain.
>
> Current code has been tested with the QEMU/Qdisk backen
>>> On 27.01.17 at 13:23, wrote:
> On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
>> >>> On 19.01.17 at 18:29, wrote:
>> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages;
>> > static long __initdata dom0_min_nrpages;
>> > static long __initdata dom0_max_nrpages = LONG_MAX;
On Thu, Jan 26, 2017 at 12:02:49PM +0200, Oleksandr Andrushchenko wrote:
> Hi, Konrad!
>
> First of all thank you very much for the valuable comments
>
> and your time!
>
> The number of changes (mostly in description) is going to
>
> be huge, so do you think I can publish something like
>
> "
On Thu, Jan 19, 2017 at 02:01:26PM +0800, Yi Sun wrote:
> This patch adds L2 CAT description in related documents.
>
> Signed-off-by: He Chen
> Signed-off-by: Yi Sun
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.
On Thu, Jan 19, 2017 at 02:01:25PM +0800, Yi Sun wrote:
> This patch implements the xl/xc changes to support set CBM
> for L2 CAT.
>
> The new level option is introduced to original CAT setting
> command in order to set CBM for specified level CAT.
> - 'xl psr-cat-cbm-set' is updated to set cache
On Thu, Jan 19, 2017 at 02:01:24PM +0800, Yi Sun wrote:
> This patch implements changes in xl/xc changes to support
> showing CBM of L2 CAT.
>
> The new level option is introduced to original CAT showing
> command in order to show CBM for specified level CAT.
> - 'xl psr-cat-show' is updated to sh
On Thu, Jan 19, 2017 at 02:01:23PM +0800, Yi Sun wrote:
> This patch implements xl/xc changes to support get HW info
> for L2 CAT.
>
> 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
> info.
>
> Example(on machine which only supports L2 CAT):
> Cache Monitoring Technology (CMT):
> Enabl
flight 104743 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 104681
test-am
On 26/01/17 20:41, Boris Ostrovsky wrote:
> PVH guests don't (yet) receive ACPI hotplug interrupts and therefore
> need to monitor xenstore for CPU hotplug event.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel m
. snip ..
> > Signed-off-by: David Woodhouse
>
> Reviewed-by: Jan Beulich
>
> But before committing I'd prefer to have a VMX maintainer ack
> too.
Who is gone until Feb yth (Spring festival in China).
___
Xen-devel mailing list
Xen-devel@lists.xen.o
On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
>> When the toolstack modifies memory of a running ARM VM it may happen
>> that the underlying memory of a current vCPU PC is changed. Without
>> flushing the icache the vCPU may cont
On 26/01/17 20:41, Boris Ostrovsky wrote:
> Using native_machine_emergency_restart (called during reboot) will
> lead PVH guests to machine_real_restart() where we try to use
> real_mode_header which is not initialized.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
On 26/01/17 20:41, Boris Ostrovsky wrote:
> Like PV guests, PVH does not have PCI devices and therefore cannot
> use MMIO space to store grants. Instead it balloons out memory and
> keeps grants there.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
___
On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> >> When the toolstack modifies memory of a running ARM VM it may happen
> >> that the underlying memory of a cur
Hello,
In developing against the altp2m API, I've encountered something I
wasn't expecting.
Here's the scenario:
1. Create a new altp2m memory view. Assume we get view ID 1.
2. Change some MFN permissions in view 1.
3. Destroy view 1.
4. Create another altp2m view. Get view ID 1 again.
Now, I
thank you for comments, please find answers below
Can we please switch to v16 discussion as v15 vs v16 is
a big change?
On 01/27/2017 05:14 PM, Konrad Rzeszutek Wilk wrote:
On Thu, Jan 26, 2017 at 12:02:49PM +0200, Oleksandr Andrushchenko wrote:
Hi, Konrad!
First of all thank you very much fo
On Jan 27, 2017 08:43, "Wei Liu" wrote:
On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrote:
> >> When the toolstack modifies memory of a running ARM VM it may happe
On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote:
> >>> On 27.01.17 at 13:23, wrote:
> > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
> >> >>> On 19.01.17 at 18:29, wrote:
> >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpages;
> >> > static long __initdata dom0_
On Fri, Jan 27, 2017 at 08:52:50AM -0700, Tamas K Lengyel wrote:
> On Jan 27, 2017 08:43, "Wei Liu" wrote:
>
> On Fri, Jan 27, 2017 at 08:37:33AM -0700, Tamas K Lengyel wrote:
> > On Fri, Jan 27, 2017 at 7:49 AM, Wei Liu wrote:
> > > On Thu, Jan 26, 2017 at 03:16:22PM -0700, Tamas K Lengyel wrot
On January 27, 2017 12:31:19 AM PST, Juergen Gross wrote:
>On 27/01/17 09:26, Oleksandr Andrushchenko wrote:
>> On 01/27/2017 10:14 AM, Juergen Gross wrote:
>>> On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
On 01/27/2017 09:46 AM, Juergen Gross wrote:
> On 27/01/17 08:21, Oleksandr An
Hello,
On 27/01/17 15:52, Tamas K Lengyel wrote:
Well, yes, only ARM could _should_ call this function. The comment I
think is important to tell the user don't expect it to do anything on
x86. Doesn't mean they can't call it though - if that was the case it
would be wrapped in an ifdef like all
On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall wrote:
> Hello,
>
> On 27/01/17 15:52, Tamas K Lengyel wrote:
>>
>> Well, yes, only ARM could _should_ call this function. The comment I
>> think is important to tell the user don't expect it to do anything on
>> x86. Doesn't mean they can't call it t
Hi Tamas,
On 27/01/17 16:23, Tamas K Lengyel wrote:
On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall wrote:
Hello,
On 27/01/17 15:52, Tamas K Lengyel wrote:
Well, yes, only ARM could _should_ call this function. The comment I
think is important to tell the user don't expect it to do anything o
>>> On 27.01.17 at 17:04, wrote:
> On Fri, Jan 27, 2017 at 08:11:56AM -0700, Jan Beulich wrote:
>> >>> On 27.01.17 at 13:23, wrote:
>> > On Thu, Jan 26, 2017 at 05:41:58AM -0700, Jan Beulich wrote:
>> >> >>> On 19.01.17 at 18:29, wrote:
>> >> > @@ -43,6 +44,9 @@ static long __initdata dom0_nrpag
On Fri, Jan 27, 2017 at 9:29 AM, Julien Grall wrote:
> Hi Tamas,
>
> On 27/01/17 16:23, Tamas K Lengyel wrote:
>>
>> On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall
>> wrote:
>>>
>>> Hello,
>>>
>>> On 27/01/17 15:52, Tamas K Lengyel wrote:
Well, yes, only ARM could _should_ call this
On Fri, Jan 27, 2017 at 09:32:25AM -0700, Tamas K Lengyel wrote:
> On Fri, Jan 27, 2017 at 9:29 AM, Julien Grall wrote:
> > Hi Tamas,
> >
> > On 27/01/17 16:23, Tamas K Lengyel wrote:
> >>
> >> On Fri, Jan 27, 2017 at 9:15 AM, Julien Grall
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> On 27/01/17 15
On Fri, Jan 27, 2017 at 05:50:36PM +0200, Oleksandr Andrushchenko wrote:
> thank you for comments, please find answers below
>
> Can we please switch to v16 discussion as v15 vs v16 is
> a big change?
This channel seemed appropiate to hash this out. I will
look at v16 next week (out of time for
>>> On 27.01.17 at 14:20, wrote:
> At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
>> On 27/01/17 11:14, Tim Deegan wrote:
>> > But looking at it now, I'm not convinced of exactly how. The magic
>> > bitmap in the TSS is at [I/O Map Base Address] - 32, and the I/O map
>> > base addres
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cac
On Thu, Jan 26, 2017 at 02:36:05PM +0800, Zhang Chen wrote:
> In this patch we close kernel COLO-Proxy on primary side.
>
> Signed-off-by: Zhang Chen
Acked-by: Wei Liu
I don't claim I know much about COLO though, nor have I ever run it, so
it would be better to have a second eye on this patch.
On Thu, Jan 26, 2017 at 02:36:09PM +0800, Zhang Chen wrote:
> We use old kernel colo proxy way to get the checkpoint event from qemu.
> This patch have some TODO job.
> Qemu compare need add a API to support this(I will add this in qemu).
>
> Signed-off-by: Zhang Chen
No major objection but this
On Thu, Jan 26, 2017 at 02:36:04PM +0800, Zhang Chen wrote:
> Add remus '-p' to enable userspace colo proxy(in qemu).
>
> Signed-off-by: Zhang Chen
> ---
> docs/man/xl.pod.1.in | 4
> tools/libxl/libxl_colo.h | 5 +
> tools/libxl/libxl_colo_save.c | 2 ++
> tools/libxl/
On Thu, Jan 26, 2017 at 02:36:03PM +0800, Zhang Chen wrote:
> Hi~ All~ Happy Chinese New Year~~
Happy Chinese New Year to you, too!
I skimmed through this series and made some comments based on my
preliminary assessment. If you have any questions, feel free to ask.
I suppose we would need to hav
On Fri, Jan 27, 2017 at 09:45:45AM -0700, Tamas K Lengyel wrote:
> When the toolstack modifies memory of a running ARM VM it may happen
> that the underlying memory of a current vCPU PC is changed. Without
> flushing the icache the vCPU may continue executing stale instructions.
>
> In this patch
On Thu, Jan 26, 2017 at 02:36:08PM +0800, Zhang Chen wrote:
> Qemu need this args to start userspace colo-proxy.
>
> Signed-off-by: Zhang Chen
See previous patch. Same comments apply here.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
On Thu, Jan 26, 2017 at 02:36:07PM +0800, Zhang Chen wrote:
> Qemu need this args to start userspace colo-proxy.
>
> Signed-off-by: Zhang Chen
Since we have:
# Note that the COLO configuration settings should be considered unstable.
# They may change incompatibly in future versions of Xen
On Thu, Jan 26, 2017 at 5:08 PM, Dario Faggioli
wrote:
> On Thu, 2017-01-26 at 13:59 -0500, Meng Xu wrote:
>> Hi Dario,
>>
> Hi,
>
>> On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli
>> wrote:
>> >
>> > Runqueue 0:
>> > CPU[00] runq=0, sibling=,0003, core=,00ff
>> >
On 01/27/2017 06:36 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 27, 2017 at 05:50:36PM +0200, Oleksandr Andrushchenko wrote:
thank you for comments, please find answers below
Can we please switch to v16 discussion as v15 vs v16 is
a big change?
This channel seemed appropiate to hash this ou
On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> >>> On 19.01.17 at 18:29, wrote:
> > @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
> > #undef MB1_PAGES
> > }
> >
> > +static int __init pvh_load_kernel(struct domain *d, const module_t *image,
> > +
Hello Tamas,
Please give a bit more time to people for reviewing before sending a new
version. Patches adding cache instruction are never easy to review.
On 27/01/17 16:45, Tamas K Lengyel wrote:
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory o
On Fri, Jan 27, 2017 at 05:22:03PM +, Roger Pau Monne wrote:
> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> > >>> On 19.01.17 at 18:29, wrote:
> > > +if ( cmdline != NULL )
> > > +{
> > > +rc = hvm_copy_to_guest_phys_vcpu(last_addr, cmdline,
> > > +
On Thu, Jan 26, 2017 at 02:36:06PM +0800, Zhang Chen wrote:
> In this patch we add a function to close
> kernel COLO-Proxy on secondary side.
>
> Signed-off-by: Zhang Chen
> ---
> tools/libxl/libxl_colo_restore.c | 9 +++--
> tools/libxl/libxl_create.c | 9 +++--
> tools/libxl/li
flight 104751 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104751/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in
104736
test-amd64-i386-xl-raw
On Fri, Jan 27, 2017 at 05:22:03PM +, Roger Pau Monne wrote:
> On Thu, Jan 26, 2017 at 06:37:00AM -0700, Jan Beulich wrote:
> > >>> On 19.01.17 at 18:29, wrote:
> > > @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
> > > #undef MB1_PAGES
> > > }
> > >
> > > +stat
On Fri, Jan 27, 2017 at 10:25 AM, Julien Grall wrote:
> Hello Tamas,
>
> Please give a bit more time to people for reviewing before sending a new
> version. Patches adding cache instruction are never easy to review.
>
> On 27/01/17 16:45, Tamas K Lengyel wrote:
>>
>> When the toolstack modifies me
On 27/01/17 16:40, Jan Beulich wrote:
On 27.01.17 at 14:20, wrote:
>> At 12:51 + on 27 Jan (1485521470), Andrew Cooper wrote:
>>> On 27/01/17 11:14, Tim Deegan wrote:
But looking at it now, I'm not convinced of exactly how. The magic
bitmap in the TSS is at [I/O Map Base Addres
(CC Artem as ARM coverity admin)
Hi Stefano,
On 03/01/17 23:29, Stefano Stabellini wrote:
Always set the new physical irq affinity at the beginning of
vgic_migrate_irq, in all cases.
No need to set physical irq affinity in gic_update_one_lr anymore,
solving the lock inversion problem.
After m
.snip..
> I am looking at this from FAE's or integrator's POV, when one would need
FAE?
> to touch different parts of the system. "/0/0/0" makes me feel
> sad just because either you have to keep all those numbers in mind (like you
> do)
> or have documentation available (and know where it is, e.
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cac
Hi Tamas,
On 27/01/17 18:17, Tamas K Lengyel wrote:
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.
In this patch we introduce VA-base
On Fri, Jan 27, 2017 at 8:44 AM, Matt Leinhos wrote:
> Hello,
>
> In developing against the altp2m API, I've encountered something I
> wasn't expecting.
>
> Here's the scenario:
>
> 1. Create a new altp2m memory view. Assume we get view ID 1.
> 2. Change some MFN permissions in view 1.
> 3. Destro
1 - 100 of 154 matches
Mail list logo
