Hi Dario,
On 20/02/2017 22:53, Dario Faggioli wrote:
On Mon, 2017-02-20 at 19:38 +, Julien Grall wrote:
On 20/02/17 19:20, Dario Faggioli wrote:
E.g., if vCPU x of domain A wants to go idle with a WFI/WFE, but
the
host is overbooked and currently really busy, Xen wants to run some
other vC
* Thomas Garnier wrote:
> > Okay, I guess I will have to wait for it to be integrated to
> > linux-next then. Or would you rather to it after this patch set is
> > added?
>
> Read your summary for the patchset of KVM cleanup, I will wait for it to
> reach
> linux-next to rebase and send the n
Hi Stefano,
On 21/02/2017 00:38, Stefano Stabellini wrote:
On Mon, 20 Feb 2017, Dario Faggioli wrote:
On Mon, 2017-02-20 at 19:38 +, Julien Grall wrote:
On 20/02/17 19:20, Dario Faggioli wrote:
E.g., if vCPU x of domain A wants to go idle with a WFI/WFE, but
the
host is overbooked and cur
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Saturday, February 18, 2017 1:40 AM
>
> vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
> for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
> bit. This is problematic:
> * For HVM guests VPMU
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Saturday, February 18, 2017 1:40 AM
>
> When toolstack overrides CPUID leaf 0xa values (on Intel processors)
> VPMU should not be available to the guest.
only when override with an invalid version?
otherwise ok to me. Reviewed-b
>>> On 21.02.17 at 00:26, wrote:
> On Mon, 20 Feb 2017, Jan Beulich wrote:
>> >>> On 17.02.17 at 23:38, wrote:
>> But the use of inline functions here is questionable
>> in the first place - so far there are none, as they're not standard
>> C89. Granted they are being used in a macro only, so won
>>> On 20.02.17 at 19:40, wrote:
> On 20/02/17 14:52, Jan Beulich wrote:
> On 20.02.17 at 14:45, wrote:
>>> On 15/02/17 11:07, Jan Beulich wrote:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -45,6 +45,8 @@
#define ModRM
>>> On 20.02.17 at 17:05, wrote:
> On 15/02/17 11:14, Jan Beulich wrote:
>> @@ -2207,12 +2231,12 @@ x86_decode_twobyte(
>> switch ( modrm_reg & 7 )
>> {
>> case 2: /* {,v}ldmxcsr */
>> -state->desc = DstImplicit | SrcMem | ModRM | Mov;
>> +state->
>>> On 21.02.17 at 07:19, wrote:
> On February 21, 2017 5:55 AM, Chao Gao wrote:
>>On Tue, Feb 21, 2017 at 04:11:53AM +, Xuquan (Quan Xu) wrote:
>>>The posted_intr_vector handler is not always pi_notification_interrupt.
>>>If the vt-d PI is not enabled, the handler is event_check_interrupt..
>
On Tue, 2017-02-21 at 07:59 +, Julien Grall wrote:
> On 20/02/2017 22:53, Dario Faggioli wrote:
> > For instance, as you say, executing a WFI from a guest directly on
> > hardware, only makes sense if we have 1:1 static pinning. Which
> > means
> > it can't just be done by default, or with a bo
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, February 17, 2017 11:43 PM
>
> During VM entry, H/W will automatically load guest's MSRs from MSR-load
> area in the same way as they would be written by WRMSR.
>
> However, under the following conditions:
>
> 1. LBR (La
>>> On 21.02.17 at 03:11, wrote:
> For a HVM domain, if a vcpu is in the nested guest mode,
> __raw_copy_to_guest() and __copy_to_guest() used by
> update_runstate_area() will copy data to L2 guest other than L1 guest.
>
> Besides copying to the wrong address, this bug also causes crash in
> the
On Tue, Feb 21, 2017 at 07:50:38AM +0800, Haozhong Zhang wrote:
> On 02/20/17 12:53 +, Wei Liu wrote:
> > > }
> > >
> > > +static int inject_lmce(xc_interface *xc_handle, uint32_t cpu_nr)
> > > +{
> > > +struct xen_mc mc;
> > > +uint8_t *cpumap = NULL;
> > > +size_t cpumap_size,
>>> On 21.02.17 at 02:32, wrote:
> +static inline void name##_read_packet(char *buf,
> \
> +RING_IDX *masked_prod, RING_IDX *masked_cons,
> \
The const/indirection problems is still there.
> +static inline void name##_write_packet(ch
On Tue, 2017-02-21 at 08:10 +, Julien Grall wrote:
> On 21/02/2017 00:38, Stefano Stabellini wrote:
> > On Mon, 20 Feb 2017, Dario Faggioli wrote:
> > > Mmm... ok, yes, in that case, it may make sense and work, from a,
> > > let's
> > > say, purely functional perspective. But still I struggle t
> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Friday, February 17, 2017 11:43 PM
>
> Replace linear scan with vmx_find_msr(). This way the time complexity
> of searching for required MSR reduces from linear to logarithmic.
>
> Signed-off-by: Sergey Dyasli
Acked-by: Kevin Tian
> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> Sent: Tuesday, February 21, 2017 12:12 PM
>
> On February 21, 2017 11:07 AM, Tian, Kevin wrote:
> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> >> Sent: Tuesday, February 21, 2017 10:49 AM
> >>
> >> On February 20, 2017 4:24 PM, Chao
On Tue, Feb 21, 2017 at 11:07:00AM +0800, Zhang Chen wrote:
>
>
> On 02/20/2017 11:59 PM, Wei Liu wrote:
> > On Fri, Feb 17, 2017 at 10:18:27AM +0800, Zhang Chen wrote:
> > > Qemu need this args to start userspace colo-proxy.
> > >
> > > Signed-off-by: Zhang Chen
> > [...]
> > > +
> > > +#undef
On Tue, Feb 21, 2017 at 10:57:46AM +0800, Zhang Chen wrote:
>
>
> On 02/20/2017 11:55 PM, Wei Liu wrote:
> > On Fri, Feb 17, 2017 at 10:18:24AM +0800, Zhang Chen wrote:
> > > In this patch we close kernel COLO-Proxy on primary side.
> > >
> > > Signed-off-by: Zhang Chen
> > > ---
> > > tools/
On Mon, Feb 20, 2017 at 10:22:06AM -0800, Stefano Stabellini wrote:
> The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
> based Dom0. It is not clear what a better default value could be.
>
> Instead, loudly warn the user when dom0_mem is unspecified and wait 3
> secs. Then use
On Fri, Feb 17, 2017 at 02:01:15PM -0600, Venu Busireddy wrote:
> On Fri, Feb 17, 2017 at 02:29:32PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 17, 2017 at 12:27:25PM -0700, Tamas K Lengyel wrote:
> > > On Fri, Feb 17, 2017 at 11:56 AM, Konrad Rzeszutek Wilk
> > > wrote:
> > > > . snip..
flight 105933 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105933/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105919
test-amd64-i386-xl-qemuu-wi
> Paolo, how stable, non-rebasing are the KVM tree commits?
Whatever ends in linux-next is stable. I have a separate rebasing branch,
but it's not part of linux-next by design.
> Or should we keep Andy's KVM patches together with the GDT patches? Either
> workflow works for me - it's your call
flight 105935 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail REGR. vs. 105855
Tests which are
Hi, Julien.
On Mon, Feb 20, 2017 at 10:31 AM, Julien Grall wrote:
> Hello Oleksandr,
>
> On 02/17/2017 08:20 PM, Oleksandr Tyshchenko wrote:
>>
>> Hi, all.
>>
>> So, as I understand we have two possible solutions for the IOMMU page
>> table to be populated:
>> 1. When the first device is being a
On 17/02/17 17:40, Boris Ostrovsky wrote:
> @@ -509,15 +498,63 @@ void vpmu_initialise(struct vcpu *v)
> if ( ret )
> printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
>
> -/* Intel needs to initialize VPMU ops even if VPMU is not in use */
> -if ( !is_pri
On 02/21/2017 05:53 PM, Wei Liu wrote:
On Tue, Feb 21, 2017 at 10:57:46AM +0800, Zhang Chen wrote:
On 02/20/2017 11:55 PM, Wei Liu wrote:
On Fri, Feb 17, 2017 at 10:18:24AM +0800, Zhang Chen wrote:
In this patch we close kernel COLO-Proxy on primary side.
Signed-off-by: Zhang Chen
---
flight 68586 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68586/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-daily-netboot-pvgrub 10 guest-start fail blocked in
68556
test-amd64-
On Tue, Feb 21, 2017 at 07:03:29PM +0800, Zhang Chen wrote:
>
>
> On 02/21/2017 05:53 PM, Wei Liu wrote:
> > On Tue, Feb 21, 2017 at 10:57:46AM +0800, Zhang Chen wrote:
> > >
> > > On 02/20/2017 11:55 PM, Wei Liu wrote:
> > > > On Fri, Feb 17, 2017 at 10:18:24AM +0800, Zhang Chen wrote:
> > > >
On 21/02/17 09:13, Tian, Kevin wrote:
>> @@ -2618,6 +2630,56 @@ static const struct lbr_info
>> *last_branch_msr_get(void)
>> return NULL;
>> }
>>
>> +enum
>> +{
>> +LBR_FORMAT_32 = 0x0, /* 32-bit record format */
>> +LBR_FORMAT_LIP= 0x1, /* 64-bit LIP
Ensure that nr_spis intialized in in vgic_init is atleast 1 to allow allocation
of
pl011 spi virq.
Signed-off-by: Bhupinder Thakur
---
xen/arch/arm/vgic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 364d5f0..614b3ec 100644
--- a/xen/a
Three new HVM param handlers added for:
- allocating a new VIRQ and return to the toolstack
- allocating a new event channel for sending/receiving events from Xen and
return
to the toolstack
- mapping the PFN allocted by the toolstack to be used as IN/OUT ring
buffers
Signed-of
Add emulation code to emulate read/write access to pl011 registers
and pl011 interrupts:
- It emulates DR read/write by reading and writing from/to the IN
and OUT ring buffers and raising an event to dom0 when there is
data in the OUT ring buffer and injecting an interrupt to the
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.
Currently, Xen supports paravirtualized (aka PV) and an emulated serial
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
for eventing
Signed-off-by: Bhupinder Thakur
---
tools/libxl/libxl.c | 6 ++
Modfication in domain_create_ring():
- Bind to the vpl011 event channel obtained from the xen store as a new
parameter
- Map the PFN to its address space to be used as IN/OUT ring buffers. It
obtains
the PFN from the xen store as a new parameter
Signed-off-by: Bhupinder Thakur
---
Based on one of the domain creation flags, the vpl011 emulation will be enabled
for
the domain.
This flag is currently set always but finally it needs to be controlled by the
user
through some configuration option.
Signed-off-by: Bhupinder Thakur
---
xen/arch/arm/domain.c | 8
xen/
Breakup evtchn_send() to allow sending events for a Xen bound channel.
Currently,
there is a check in evtchn_send() i.e. is_consumer_xen() that if the event
channel
is bound to a xen consumer then event generation is not allowed for that
channel.
This check is to disallow a guest from raising an
Allocates a new pfn, initializes it and passes on to Xen using a hvm call.
Another changes is in xc_hvm_param_deprecated_check () to allow new vpl011 HVM
params,
which have been defined to some deprecated HVM params.
Signed-off-by: Bhupinder Thakur
---
tools/libxc/include/xc_dom.h | 5 +
t
MOdifications in the following functions:
- handle_ring_read() - to allow reading data from both PV or vpl011 OUT
ring buffers
based on which port received the event
- buffer_append() - append data received for either PV or vp011 OUT ring
buffer
Signed-off-by: Bhupinder Thakur
--
Add a new pl011 uart node
- Get the pl011 spi virq from Xen using a hvm call
- Add a new device tree node in the guest DT for SBSA pl011 uart containing
the IRQ
(read above) and the MMIO address range to be used by the guest
The format for the node is specified in
Documentation/dev
Modification in handle_tty_read to write the user data to the vpl011 IN ring
buffer.
Finally this needs to be modified to allow user input for both PV and vpl011
consoles.
Signed-off-by: Bhupinder Thakur
---
tools/console/daemon/io.c | 19 +--
1 file changed, 17 insertions(+),
On 20/02/2017 20:54, Peter Zijlstra wrote:
> On Mon, Feb 20, 2017 at 01:36:02PM -0500, Waiman Long wrote:
>> Waiman Long (2):
>> x86/paravirt: Change vcp_is_preempted() arg type to long
>> x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64
>>
>> arch/x86/include/asm/paravir
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Wei Liu
---
tools/xentrace/xenalyze.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index a90da20..b2d1b6a 100644
--- a/tools/xentrace/xenalyze
flight 105937 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105937/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5af4388433e13ffeda980116d92f4230c79e483d
baseline version:
ovmf c035e37335ae43229d7e6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2017-2620 / XSA-209
version 3
cirrus_bitblt_cputovideo does not check if memory region is safe
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
==
The Xenstore protocol supports the XS_DEBUG command for triggering
various actions in the Xenstore daemon. Enhance that support by using
a command table and adding a help function. Move all the XS_DEBUG
related code to a new source file xenstored_debug.c.
Support multiple debug commands in the ass
Today xenstored supports logging only via a command line parameter.
This means that logging is either all the time off (default) or on.
To switch logging on the Xen host has to be rebooted as xenstored
isn't restartable.
This patch series changes this by using the XS_DEBUG wire command of
Xenstore
As a memory report can now be triggered via XS_DEBUG support via
command line and signal handler is no longer needed. Remove it.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 35 ++-
1 file changed, 2 insertions(+), 33 deletions(-)
diff --git
Add a XS_DEBUG command to xenstored for doing a talloc report to a
file. Right now this is supported by specifying a command line option
when starting xenstored and sending a signal to the daemon to trigger
the report.
To dump the report to the standard log file call:
xenstore-control memreport
Today Xenstore supports logging only if specified at start of the
Xenstore daemon. As it can't be disabled during runtime it is not
recommended to start xenstored with logging enabled.
Add support for switching logging on and off at runtime and to
specify a (new) logfile. This is done via the XS_D
Hi,
I was trying out xen in salvator-X(M3 Board as described in
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
I ran in to following error:
U-Boot 2015.04 (Feb 21 2017 - 14:24:48)
CPU: Renesas Electronics R8A7796 rev 1.0
Board: Salvator-X
I2C: ready
DRAM:
On Tue, Feb 21, 2017 at 01:00:58PM +0100, Juergen Gross wrote:
> Add a XS_DEBUG command to xenstored for doing a talloc report to a
> file. Right now this is supported by specifying a command line option
> when starting xenstored and sending a signal to the daemon to trigger
> the report.
>
> To d
Hi Dario,
On 21/02/2017 09:09, Dario Faggioli wrote:
On Tue, 2017-02-21 at 07:59 +, Julien Grall wrote:
On 20/02/2017 22:53, Dario Faggioli wrote:
For instance, as you say, executing a WFI from a guest directly on
hardware, only makes sense if we have 1:1 static pinning. Which
means
it can
Block backends defined with -drive if=ide are meant to be picked up by
machine initialization code: a suitable frontend gets created and
wired up automatically.
if=ide drives not picked up that way can still be used with -device as
if they had if=none, but that's unclean and best avoided. Unused
On 21/02/17 13:16, Wei Liu wrote:
> On Tue, Feb 21, 2017 at 01:00:58PM +0100, Juergen Gross wrote:
>> Add a XS_DEBUG command to xenstored for doing a talloc report to a
>> file. Right now this is supported by specifying a command line option
>> when starting xenstored and sending a signal to the da
On Tue, Feb 21, 2017 at 01:36:58PM +0100, Juergen Gross wrote:
> On 21/02/17 13:16, Wei Liu wrote:
> > On Tue, Feb 21, 2017 at 01:00:58PM +0100, Juergen Gross wrote:
> >> Add a XS_DEBUG command to xenstored for doing a talloc report to a
> >> file. Right now this is supported by specifying a comman
flight 105936 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105936/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 3 host-install(3) broken in 105926 pass in 105936
test-armhf-armhf-xl-credit2 1
flight 105938 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105938/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105921
test-armhf-armhf-libvirt 13
On Mon, Feb 20, 2017 at 05:18:44PM +, Wei Liu wrote:
> On Fri, Feb 17, 2017 at 01:36:01PM +0100, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I'm adjusting python bindings to work on python3 too. This will require
> > few #if in the code (to compile for both python2 and python3), but it
>
Hi Dario,
On 21/02/17 09:24, Dario Faggioli wrote:
On Tue, 2017-02-21 at 08:10 +, Julien Grall wrote:
On 21/02/2017 00:38, Stefano Stabellini wrote:
On Mon, 20 Feb 2017, Dario Faggioli wrote:
Mmm... ok, yes, in that case, it may make sense and work, from a,
let's
say, purely functional pe
On 02/21/2017 07:18 PM, Wei Liu wrote:
On Tue, Feb 21, 2017 at 07:03:29PM +0800, Zhang Chen wrote:
On 02/21/2017 05:53 PM, Wei Liu wrote:
On Tue, Feb 21, 2017 at 10:57:46AM +0800, Zhang Chen wrote:
On 02/20/2017 11:55 PM, Wei Liu wrote:
On Fri, Feb 17, 2017 at 10:18:24AM +0800, Zhang Chen
On 02/20/2017 05:28 AM, Andrew Cooper wrote:
> The current hvm_msr_{read,write}_intercept() infrastructure calls
> hvm_inject_hw_exception() directly to latch a fault, and returns
> X86EMUL_EXCEPTION to its caller.
>
> This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
>
On 21/02/17 12:30, Julien Grall wrote:
> Hi Dario,
>
> On 21/02/2017 09:09, Dario Faggioli wrote:
>> On Tue, 2017-02-21 at 07:59 +, Julien Grall wrote:
>>> On 20/02/2017 22:53, Dario Faggioli wrote:
For instance, as you say, executing a WFI from a guest directly on
hardware, only mak
flight 105950 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105950/
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
build-arm64 5 xen
On 02/20/2017 05:42 AM, Roger Pau Monne wrote:
> On Mon, Feb 20, 2017 at 12:20:10AM +, Andrew Cooper wrote:
>> From
>> http://logs.test-lab.xenproject.org/osstest/logs/105917/test-amd64-amd64-xl-pvh-intel/serial-fiano0.log
>> around Feb 19 23:12:06.269706
>>
>> (XEN) [ Xen-4.9-unstable x86
On 21/02/17 13:46, Boris Ostrovsky wrote:
>> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
>> index 894c457..b864535 100644
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1744,7 +1744,6 @@ static int svm_msr_read_intercept(unsigned int msr,
>>
On 02/21/2017 03:09 AM, Tian, Kevin wrote:
>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>> Sent: Saturday, February 18, 2017 1:40 AM
>>
>> vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
>> for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
>> b
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.11-rc0-tag
It contains:
- a series from Boris Ostrovsky adding support for booting Linux as
Xen PVH guest
- a series from Juergen Gross streamlining the xenbus driver
- a series fr
On 02/21/2017 06:00 AM, Andrew Cooper wrote:
> On 17/02/17 17:40, Boris Ostrovsky wrote:
>> @@ -509,15 +498,63 @@ void vpmu_initialise(struct vcpu *v)
>> if ( ret )
>> printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
>>
>> -/* Intel needs to initialize VPMU o
As a memory report can now be triggered via XS_CONTROL support via
command line and signal handler is no longer needed. Remove it.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c | 35 ++-
1 file changed, 2 insertions(+), 33 deletions(-)
diff --g
In preparation to support other than pure debug functionality via the
Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
XS_DEBUG an alias of it.
Add an alias xs_control_command for the associated xs_debug_command,
too.
Signed-off-by: Juergen Gross
---
tools/xenstore/include/xensto
Today xenstored supports logging only via a command line parameter.
This means that logging is either all the time off (default) or on.
To switch logging on the Xen host has to be rebooted as xenstored
isn't restartable.
This patch series changes this by using the XS_DEBUG wire command of
Xenstore
Add a XS_CONTROL command to xenstored for doing a talloc report to a
file. Right now this is supported by specifying a command line option
when starting xenstored and sending a signal to the daemon to trigger
the report.
To dump the report to the standard log file call:
xenstore-control memreport
Today Xenstore supports logging only if specified at start of the
Xenstore daemon. As it can't be disabled during runtime it is not
recommended to start xenstored with logging enabled.
Add support for switching logging on and off at runtime and to
specify a (new) logfile. This is done via the XS_C
The Xenstore protocol supports the XS_CONTROL command for triggering
various actions in the Xenstore daemon. Enhance that support by using
a command table and adding a help function. Move all the XS_CONTROL
related code to a new source file xenstored_control.c.
Support multiple control commands in
On Tue, 2017-02-21 at 13:46 +, George Dunlap wrote:
>
> A. Don't trap guest WFI at all -- allow it to 'halt' in
> moderate-power-but-ready-for-interrupt mode.
>
> [..]
>
> A is safe because the scheduler should already have set a timer to
> break
> out of it if necessary. The only potential
Hi George,
On 21/02/17 13:46, George Dunlap wrote:
I think our options look like:
Thank you for the summary of the options!
A. Don't trap guest WFI at all -- allow it to 'halt' in
moderate-power-but-ready-for-interrupt mode.
B. Trap guest WFI and block normally.
C. Trap guest WFI and pol
On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
>> Revert the main part of commit:
>> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>>
>> That commit introduced reading the pci device's msi messa
On 21/02/17 16:31, Dan Streetman wrote:
> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
>>> Revert the main part of commit:
>>> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>>>
>>> That com
Xl has grown sufficiently large to warrnant its own directory. We also need
clear separation between the client (xl) and library (libxl).
This patch series moves xl into tools/xl directory.
Use find to generate a list of files to be installed from staging and wip
branch, then `diff -q staging w
We are about to split out xl (which depends on libxlutil) to a different
directory. Provide the proper options for compiling and linking in
Rules.mk, and replace the hardcoded string in libxl/Makefile.
No functional change.
Signed-off-by: Wei Liu
---
tools/Rules.mk | 7 +++
tools/libx
It makes clear distinction between the client (xl) and library (libxl),
which should help design better APIs. This will also help reduce the
code size in libxl directory.
Signed-off-by: Wei Liu
---
.gitignore | 2 +-
tools/libxl/Makefile| 22 ---
On 02/21/2017 10:45 AM, Juergen Gross wrote:
> On 21/02/17 16:31, Dan Streetman wrote:
>> On Fri, Jan 13, 2017 at 5:30 PM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup
>>> On 20.02.17 at 12:00, wrote:
> On real hardware, the bulk of CPUID data is system-specific and constant.
> Hold the toolstack to the same behaviour when constructing domains.
>
> Values which are expected to change dynamically (e.g. OSXSAVE) are
> unaffected
> and continue to function as bef
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -225,9 +225,13 @@ def crunch_numbers(state):
> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
> AVX, MPX, PKU, LWP],
>
> -# AVX is taken to mean hardware support for
On 21/02/17 16:40, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>> AVX, MPX, PKU, LWP],
>>
>> -
>>> On 21.02.17 at 17:40, wrote:
On 20.02.17 at 12:00, wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>> AVX, MPX, PKU, LWP],
>>
>> -#
On Tue, 2017-02-21 at 12:30 +, Julien Grall wrote:
> On 21/02/2017 09:09, Dario Faggioli wrote:
> > Well, TBH, we still are not entirely sure who the culprit is for
> > high
> > latency. There are spikes in Credit2, and I'm investigating that.
> > But
> > apart from them? I think we need other
This run is configured for baseline tests only.
flight 68588 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot
On 21/02/17 16:47, Jan Beulich wrote:
On 21.02.17 at 17:40, wrote:
> On 20.02.17 at 12:00, wrote:
>>> --- a/xen/tools/gen-cpuid.py
>>> +++ b/xen/tools/gen-cpuid.py
>>> @@ -225,9 +225,13 @@ def crunch_numbers(state):
>>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
>>>
flight 105953 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105953/
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
build-arm64 5 xen
On 21/02/17 15:14, Julien Grall wrote:
> Hi George,
>
> On 21/02/17 13:46, George Dunlap wrote:
>> I think our options look like:
>
> Thank you for the summary of the options!
>
>>
>> A. Don't trap guest WFI at all -- allow it to 'halt' in
>> moderate-power-but-ready-for-interrupt mode.
>>
>> B
>>> On 20.02.17 at 12:00, wrote:
> The ebx word is more problematic. The low 8 bits are the brand ID and safe to
> pass straight through. The next 8 bits are the CLFLUSH line size. This value
> is forwarded straight from hardware, as nothing good can possibly come of
> providing an alternative
>>> On 21.02.17 at 17:53, wrote:
> On 21/02/17 16:47, Jan Beulich wrote:
> On 21.02.17 at 17:40, wrote:
>> On 20.02.17 at 12:00, wrote:
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -225,9 +225,13 @@ def crunch_numbers(state):
XSAVE: [XSAVEOPT,
On 21/02/17 17:07, Jan Beulich wrote:
On 21.02.17 at 17:53, wrote:
>> On 21/02/17 16:47, Jan Beulich wrote:
>> On 21.02.17 at 17:40, wrote:
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -225,9 +225,13 @@ def crunch_nu
On 21/02/17 16:59, Jan Beulich wrote:
On 20.02.17 at 12:00, wrote:
>> The ebx word is more problematic. The low 8 bits are the brand ID and safe
>> to
>> pass straight through. The next 8 bits are the CLFLUSH line size. This
>> value
>> is forwarded straight from hardware, as nothing goo
>>> On 20.02.17 at 12:00, wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -163,6 +163,9 @@ static void recalculate_xstate(struct cpuid_policy *p)
> */
> static void recalculate_misc(struct cpuid_policy *p)
> {
> +/* Leaves with subleaf unions. */
> +p->basic.raw[0
>>> On 21.02.17 at 18:12, wrote:
> Which particular feature groups? I could extend that text to say
>
> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and
> $X sets..."
TBM and LWP.
Jan
___
Xen-devel mailing list
Xen-devel@lists
>>> On 21.02.17 at 18:13, wrote:
> On 21/02/17 16:59, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> The ebx word is more problematic. The low 8 bits are the brand ID and safe
>>> to
>>> pass straight through. The next 8 bits are the CLFLUSH line size. This
>>> value
>>> is forwar
1 - 100 of 176 matches
Mail list logo
