>>> On 05.02.16 at 14:42, wrote:
> A single ctxt_switch_levelling() function pointer is provided
> (defaulting to an empty nop), which is overridden in the appropriate
> $VENDOR_init_levelling().
>
> set_cpuid_faulting() is made private and included within
> intel_ctxt_switch_levelling().
>
> On
>>> On 05.02.16 at 14:42, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -208,7 +208,9 @@ static void __init noinline probe_masking_msrs(void)
> static void amd_ctxt_switch_levelling(const struct domain *nextd)
> {
> struct cpuidmasks *these_masks = &this_cpu(cpu
>>> On 16.02.16 at 15:15, wrote:
On 05.02.16 at 14:42, wrote:
>> --- a/xen/include/asm-x86/processor.h
>> +++ b/xen/include/asm-x86/processor.h
>> @@ -574,6 +574,34 @@ void microcode_set_module(unsigned int);
>> int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void), unsigned long len);
>>
>>> On 05.02.16 at 14:42, wrote:
> @@ -87,6 +88,93 @@ static void update_domain_cpuid_info(struct domain *d,
> d->arch.x86_model = (ctl->eax >> 4) & 0xf;
> if ( d->arch.x86 >= 0x6 )
> d->arch.x86_model |= (ctl->eax >> 12) & 0xf0;
> +
> +if ( is_pv_domain(d) )
>>> On 05.02.16 at 14:42, wrote:
> @@ -190,6 +191,71 @@ long arch_do_sysctl(
> }
> break;
>
> +case XEN_SYSCTL_get_cpu_featureset:
> +{
> +const uint32_t *featureset;
> +unsigned int nr;
> +
> +/* Request for maximum number of features? */
> +
>>> On 05.02.16 at 14:42, wrote:
> @@ -467,11 +420,8 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
> regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
> break;
> case 1: /* leaf 1 */
> -regs[0] &= (XSAVEOPT | XSAVEC | XGETBV1 | XSAVES);
> -if ( !info-
On 02/16/2016 07:11 PM, Andrew Cooper wrote:
snip
+}
+
+barrier(); /* MUST do it after get_cpu_maps. */
+total_cpus = num_online_cpus() - 1;
+
+if ( total_cpus )
+{
+printk(XENLOG_DEBUG "%s: CPU%u - IPIing the %u CPUs.\n", p->name,
+
> -Original Message-
[snip]
> > > >
> > > > I'm afraid I have made little progress due to the distractions of trying
> get
> > > > some patches into Linux but my thoughts are around replacing the
> > > > HVM_mmio_write_dm with something like HVM_emulate_0 (i.e. the
> zero-
> > > th example
On 02/15/16 04:07, Jan Beulich wrote:
> >>> On 15.02.16 at 09:43, wrote:
> > On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
> >> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
> >> > three parts:
> >> > (1) Guest clwb/clflushopt/pcommit enabling,
> >> > (2) Memory map
>>> On 08.02.16 at 18:26, wrote:
This fiddles with behavior on AMD only, yet it's not obvious why this
couldn't be done in vendor independent code (it should, afaict, be
benign for Intel).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http:/
On 02/16/16 05:55, Jan Beulich wrote:
> >>> On 16.02.16 at 12:14, wrote:
> > On Mon, 15 Feb 2016, Zhang, Haozhong wrote:
> >> On 02/04/16 20:24, Stefano Stabellini wrote:
> >> > On Thu, 4 Feb 2016, Haozhong Zhang wrote:
> >> > > On 02/03/16 15:22, Stefano Stabellini wrote:
> >> > > > On Wed, 3 Feb
>>> On 17.02.16 at 10:01, wrote:
> On 02/15/16 04:07, Jan Beulich wrote:
>> >>> On 15.02.16 at 09:43, wrote:
>> > On 02/03/16 03:15, Konrad Rzeszutek Wilk wrote:
>> >> > Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
>> >> > three parts:
>> >> > (1) Guest clwb/clflushopt
On Tue, Feb 16, 2016 at 09:48:58PM -0800, Andy Lutomirski wrote:
> On Tue, Feb 2, 2016 at 9:46 PM, Andy Lutomirski wrote:
> > This switches virtio to use the DMA API on Xen and if requested by
> > module option.
>
> Michael, any update on this?
>
> --Andy
I was hoping for an explicit ack from D
>>> On 17.02.16 at 09:58, wrote:
>> > I'd envisaged that setting HVM_emulate_0 type on a page would mean
>> nothing until an
>>
>> for "mean nothing" what is the default policy then if guest happens to access
>> it
>> before any ioreq server claims it?
>>
>
> My thoughts were that, since no spe
On Wed, 2016-02-17 at 11:29 +0200, Michael S. Tsirkin wrote:
>
> I was hoping for an explicit ack from David Woodhouse,
> but I guess the informal "let's not hold this up"
> that was sent on v5 will do.
Apologies; I was working under that assumption too.
--
dwmw2
smime.p7s
Description: S/MIM
On Tue, 2016-02-16 at 17:54 +, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] MAINTAINERS: add myself as seabios maintainer"):
> > SEABIOS UPSTREAM
> > M: Ian Campbell
> > +M: Wei Liu
> > S: Supported
> > T: git git://xenbits.xen.org/seabios.git
>
> Acked-by: Ian Jackson
Acked-by: Ian C
On Tue, 2016-02-16 at 13:21 -0500, Meng Xu wrote:
> Hi Dario,
>
> Since this patch did some obvious change, I will reply with
> reviewed-by, although my reviewed-by does not count much. ;-)
>
That can't be less true. First of all, you're the original author of
this code, and you and, although I'm
>>> On 16.02.16 at 16:00, wrote:
> v3:
> - Use XEN_NETIF_ prefix instead of NETIF_
Stale patch? Because I can't see this having happened ...
> @@ -206,10 +206,10 @@
> * Buffer[0..8] = Packet[12..15] (source address) +
> *Packet[16..19] (destination address)
> *
> - * Resu
>>> On 16.02.16 at 22:26, wrote:
> On 02/16/2016 12:37 PM, Roger Pau Monne wrote:
>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>> index 7b629b1..6ba060f 100644
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -787,25 +787,46 @@ typedef struct start_i
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Wednesday, February 17, 2016 4:58 PM
>
> >
> > btw does this design consider the case where multiple ioreq servers
> > may claim on same page?
>
> Yes it does and there are currently insufficient page types to allow any more
> than a
On Tue, 2016-02-16 at 23:20 +, Wei Liu wrote:
> On Tue, Feb 16, 2016 at 03:09:37PM -0700, Jim Fehlig wrote:
> > Wei Liu wrote:
> > > This patch series consolidates adhoc parsers in xl.
> >
> > Hi Wei,
> >
> > I never tested or reviewed this series after seeing Ian's comments. Did
> > you have
El 16/2/16 a les 21:06, Konrad Rzeszutek Wilk ha escrit:
> On Tue, Feb 16, 2016 at 06:37:46PM +0100, Roger Pau Monne wrote:
>> After some discussion around the new boot ABI consensus has been reached
>> about the layout and contents of the start info. The following patch updates
>> the layout to wh
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 February 2016 09:52
> To: Paul Durrant
> Cc: Ian Campbell; Ian Jackson; xen-de...@lists.xenproject.org; Keir
> (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v3] public/io/netif.h: make control ring hash protocol
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: 17 February 2016 09:58
> To: Paul Durrant; Jan Beulich
> Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Stefano
> Stabellini; Wei Liu; Lv, Zhiyuan; Zhang Yu; xen-devel@lists.xen.org; George
> Dunlap
El 17/2/16 a les 10:58, Jan Beulich ha escrit:
On 16.02.16 at 22:26, wrote:
>> On 02/16/2016 12:37 PM, Roger Pau Monne wrote:
>>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
>>> index 7b629b1..6ba060f 100644
>>> --- a/xen/include/public/xen.h
>>> +++ b/xen/include/public/
On Tue, 2016-02-16 at 20:54 -0700, Jim Fehlig wrote:
> When dequoting config strings in xlu__cfgl_dequote(), unknown
> characters following a '\', and the '\' itself, are discarded.
> E.g. a disk configuration string containing
>
> rbd:pool/image:mon_host=192.168.0.100\:6789
>
> would be dequot
On Tue, 2016-02-16 at 20:54 -0700, Jim Fehlig wrote:
Missing S-o-b, otherwise:
Acked-by: Ian Campbell
> ---
> docs/misc/xl-disk-configuration.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/docs/misc/xl-disk-configuration.txt b/docs/misc/xl-disk-
> configuration.tx
On Tue, 2016-02-16 at 20:54 -0700, Jim Fehlig wrote:
> target= in disk config can be used to convey arbitrary
> configuration information to backends. Add a bit more info
> to xl-disk-configuration.txt to clarify this, including some
> simple nbd and rbd qdisk configurations.
Missing S-o-b.
> ---
On Wed, 2016-02-17 at 10:05 +, Ian Campbell wrote:
> On Tue, 2016-02-16 at 20:54 -0700, Jim Fehlig wrote:
> > When dequoting config strings in xlu__cfgl_dequote(), unknown
> > characters following a '\', and the '\' itself, are discarded.
> > E.g. a disk configuration string containing
> >
> >
Hi all,
Could anyone tell me if and how I could pass some GCC extra compilation flags
when building Xen (i.e. make dist-xen)?
I tried:
* when running make: passing EXTRA_CFLAGS
* when running make: passing CFLAGS (this "works" but overrides the rest of the
CFLAGS)
* when running ./configure: pa
>>> On 17.02.16 at 10:58, wrote:
> Thanks for the help. Let's see whether we can have some solution ready for
> 4.7. :-)
Since we now seem to all agree that a different approach is going to
be taken, I think we indeed should revert f5a32c5b8e ("x86/HVM:
differentiate IO/mem resources tracked by
> Could anyone tell me if and how I could pass some GCC extra compilation
> flags when building Xen (i.e. make dist-xen)?
> I tried:
> * when running make: passing EXTRA_CFLAGS
> * when running make: passing CFLAGS (this "works" but overrides the rest
> of the CFLAGS)
> * when running ./configure:
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 17 February 2016 10:22
> To: Paul Durrant; Kevin Tian; Zhang Yu
> Cc: Andrew Cooper; George Dunlap; Ian Campbell; Ian Jackson; Stefano
> Stabellini; Wei Liu; Zhiyuan Lv; xen-devel@lists.xen.org; George Dunlap; Keir
On Tue, 2016-02-16 at 14:45 -0700, Jim Fehlig wrote:
> xl/libxl already supports qemu's network-based block backends
> such as nbd and rbd. libvirt has supported configuring network
> disks for long time too. This series marries the two in the
> libxl driver and in the xl<->xml converter. Only rbd
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Wednesday, February 17, 2016 6:24 PM
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 17 February 2016 10:22
> > To: Paul Durrant; Kevin Tian; Zhang Yu
> > Cc: Andrew Cooper; George Dunlap; Ian
On 16/02/16 09:54, Jan Beulich wrote:
On 15.02.16 at 20:07, wrote:
>> On 15/02/16 16:27, Jan Beulich wrote:
>> On 15.02.16 at 17:09, wrote:
On 15/02/16 15:52, Jan Beulich wrote:
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -138,6 +138,61 @@
flight 82845 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82845/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
The contents of /proc/uptime is typically something like "80164.57
640617.58", so the existing 512 byte buffer is more than large enoguh,
so reduce its effective size to 511 bytes and ensure we include a
NULL.
Otherwise Coverity points out that we pass a potentially unterminated
string to strtok.
Dom0 is handled separately (via print_dom0_uptime) and the domU
variant doesn't work for dom0 since libxl_vm_get_start_time() doesn't.
Signed-off-by: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/
>>> On 17.02.16 at 11:19, wrote:
> Could anyone tell me if and how I could pass some GCC extra compilation
> flags when building Xen (i.e. make dist-xen)?
> I tried:
> * when running make: passing EXTRA_CFLAGS
> * when running make: passing CFLAGS (this "works" but overrides the rest of
> the CF
On 2/17/2016 12:23 PM, Razvan Cojocaru wrote:
Could anyone tell me if and how I could pass some GCC extra compilation
flags when building Xen (i.e. make dist-xen)?
I tried:
* when running make: passing EXTRA_CFLAGS
* when running make: passing CFLAGS (this "works" but overrides the rest
of the CF
We assert that nullfd if not std{in,out,err} since that would result
in closing one of the just dup2'd fds. For this to happen
std{in,out,err} would have needed to be closed, at which point all
sorts of other things could go wrong.
CID: 1130519
It was previously hypothesised[0] that fixing 113051
On 16/02/16 10:06, Jan Beulich wrote:
On 15.02.16 at 18:12, wrote:
>> On 15/02/16 15:43, Jan Beulich wrote:
>> On 05.02.16 at 14:42, wrote:
@@ -4617,50 +4618,39 @@ void hvm_cpuid(unsigned int input, unsigned int
*eax, unsigned int *ebx,
/* Fix up VLAPIC details.
>>> On 17.02.16 at 11:25, wrote:
> On 16/02/16 09:54, Jan Beulich wrote:
> On 15.02.16 at 20:07, wrote:
>>> On 15/02/16 16:27, Jan Beulich wrote:
>>> On 15.02.16 at 17:09, wrote:
> The key point is this. If I choose to enable XSAVE and disable AVX for
> a domain, that domain is
On 16/02/16 14:10, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
>> commandline-provided masks would take effect in Xen's view of the features.
>>
>> As the masks got applied after the query for features, the red
Roger Pau Monne, on Tue 16 Feb 2016 18:37:46 +0100, wrote:
> After some discussion around the new boot ABI consensus has been reached
> about the layout and contents of the start info. The following patch updates
> the layout to what has been agreed.
>
> Also, the new layout is described in binary
On 17/02/16 08:15, Jan Beulich wrote:
On 16.02.16 at 15:15, wrote:
> On 05.02.16 at 14:42, wrote:
>>> --- a/xen/include/asm-x86/processor.h
>>> +++ b/xen/include/asm-x86/processor.h
>>> @@ -574,6 +574,34 @@ void microcode_set_module(unsigned int);
>>> int microcode_update(XEN_GUEST_HAND
>>> On 16.02.16 at 20:11, wrote:
> On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
>> +void xsplice_revert_jmp(struct xsplice_patch_func *func)
>> +{
>> +memcpy((void *)func->old_addr, func->undo, PATCH_INSN_SIZE);
>
> _p() is common shorthand in Xen for a cast to (void *)
Iirc this was mean
c5e29f93fb6e "mg-show-flight-runvars: recurse on buildjobs upon
request" broke standalone mode with:
Error: no such column: TRUE
from sqlite. Do as is done for $syntcond and use (1=1) instead.
Signed-off-by: Ian Campbell
---
mg-show-flight-runvars | 2 +-
1 file changed, 1 insertion(+), 1 de
>>> On 17.02.16 at 11:43, wrote:
> On 16/02/16 10:06, Jan Beulich wrote:
> On 15.02.16 at 18:12, wrote:
>>> On 15/02/16 15:43, Jan Beulich wrote:
>>> On 05.02.16 at 14:42, wrote:
> @@ -4617,50 +4618,39 @@ void hvm_cpuid(unsigned int input, unsigned int
> *eax, unsigned int *ebx,
On 17/02/16 07:40, Jan Beulich wrote:
>
>> +if ((rdmsr_amd_safe(msr, &lo, &hi) == 0) &&
>> +(wrmsr_amd_safe(msr, lo, hi) == 0))
>> +levelling_caps |= caps;
>> +
>> +*msr_val = ((uint64_t)hi << 32) | lo;
>> +}
> Why can't this function, currently returning void, simply re
>>> On 17.02.16 at 11:45, wrote:
> On 16/02/16 14:10, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
>>> commandline-provided masks would take effect in Xen's view of the features.
>>>
>>> As the masks got appl
On 17/02/16 07:57, Jan Beulich wrote:
>
>> +/* Indicies of the masking MSRs, or 0 if unavailable. */
>> +static unsigned int __read_mostly msr_basic, msr_ext, msr_xsave;
> I think this way __read_mostly applies only to msr_basic, which I
> don't think is what you want. Also I think you mean "indice
Hello,
to answer my own questions:
Am 16.02.2016 um 16:38 schrieb Philipp Hahn:
> Summary: When a Linux-PV-domU is migrated between two hosts, the
> "ntpdate" time jumps.
...
> 1. If I start a new domU (just kernel and InitRamFS with busybox as to
> minimize the processes involved), the wall-cloc
On 17/02/16 10:22, Jan Beulich wrote:
On 17.02.16 at 10:58, wrote:
>> Thanks for the help. Let's see whether we can have some solution ready for
>> 4.7. :-)
>
> Since we now seem to all agree that a different approach is going to
> be taken, I think we indeed should revert f5a32c5b8e ("x86/
Coverity rightly points out that qmp->buffer may not be NULL
terminated when passed to strncat.
Make the actual buffer a byte bigger than QMP_RECEIVE_BUFFER_SIZE and
always append a NULL byte.
I suspect that in practice we have not yet seen QMP messages
approaching the buffer size (4K).
Compile
On 17/02/16 08:13, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -208,7 +208,9 @@ static void __init noinline probe_masking_msrs(void)
>> static void amd_ctxt_switch_levelling(const struct domain *nextd)
>> {
>> st
>>> On 16.02.16 at 21:20, wrote:
> On 12/02/16 18:05, Konrad Rzeszutek Wilk wrote:
>> +static void xsplice_print_build_id(char *id, unsigned int len)
>> +{
>> +unsigned int i;
>> +
>> +if ( !len )
>> +return;
>> +
>> +for ( i = 0; i < len; i++ )
>> +{
>> +uint8_t c
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 17 February 2016 11:02
> To: Jan Beulich; Paul Durrant; Kevin Tian; Zhang Yu
> Cc: Andrew Cooper; Ian Campbell; Ian Jackson; Stefano Stabellini; Wei Liu;
> Zhiyuan Lv; xen-devel@lists.xen.org; George Dunlap
>>> On 17.02.16 at 12:03, wrote:
> On 17/02/16 08:13, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> --- a/xen/arch/x86/cpu/amd.c
>>> +++ b/xen/arch/x86/cpu/amd.c
>>> @@ -208,7 +208,9 @@ static void __init noinline probe_masking_msrs(void)
>>> static void amd_ctxt_switch_levelling(con
On Tue, Feb 16, Ian Jackson wrote:
> Olaf Hering writes ("Re: [PATCH v8 3/5] libxl: add support for vscsi"):
> > On Mon, Feb 15, Ian Jackson wrote:
> > > One reason you might define a virtual controller with no devices yet
> > > is so that you have a stable and pre-expected device path for any
> >
El 16/2/16 a les 18:58, Ian Jackson ha escrit:
> Roger Pau Monne writes ("[PATCH v4 4/4] libxl: fix cd-eject"):
>> Current libxl__device_disk_set_backend implementation tried to guess the
>> backend of devices with format LIBXL_DISK_FORMAT_EMPTY, which is of course
>> doomed to fail since the disk
Konrad Rzeszutek Wilk writes ("[PATCH v3 2/3] XENVER_build_id: Provide
ld-embedded build-ids (v8)"):
> The mechanism to get this is via the XENVER hypercall and
> we add a new sub-command to retrieve the binary build-id
> called XENVER_build_id. The sub-hypercall parameter
> allows an arbitrary si
On Wed, 2016-02-17 at 01:39 +, osstest service owner wrote:
> flight 82793 linux-3.18 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/82793/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-rumpuserxe
On Tue, Feb 16, 2016 at 05:53:18PM +, Ian Jackson wrote:
> Jim Fehlig writes ("Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands"):
> > I just noticed this is the case with network devices as well. E.g.
> >
> > #xl network-attach hvm-domU mac=00:16:3e:xx:yy:zz,bridge=br0
> > libxl: error:
On Wed, 2016-02-17 at 12:20 +0100, Roger Pau Monné wrote:
> El 16/2/16 a les 18:58, Ian Jackson ha escrit:
> > Roger Pau Monne writes ("[PATCH v4 4/4] libxl: fix cd-eject"):
> > > Current libxl__device_disk_set_backend implementation tried to guess
> > > the
> > > backend of devices with format LIB
On Wed, Feb 17, 2016 at 10:01:37AM +, Ian Campbell wrote:
> On Tue, 2016-02-16 at 23:20 +, Wei Liu wrote:
> > On Tue, Feb 16, 2016 at 03:09:37PM -0700, Jim Fehlig wrote:
> > > Wei Liu wrote:
> > > > This patch series consolidates adhoc parsers in xl.
> > >
> > > Hi Wei,
> > >
> > > I neve
On 17/02/16 08:22, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> @@ -87,6 +88,93 @@ static void update_domain_cpuid_info(struct domain *d,
>> d->arch.x86_model = (ctl->eax >> 4) & 0xf;
>> if ( d->arch.x86 >= 0x6 )
>> d->arch.x86_model |= (ctl->eax >> 12) &
Roger Pau Monné writes ("Re: [PATCH v4 4/4] libxl: fix cd-eject"):
> Should we allow the PHY backend to handle empty files?
> (pdev_path == NULL || pdev_path == "").
Yes. That is how it is supposed to work.
I think this was broken in in 97ee1f5d "libxl: add support for image
files for NetBSD" in
On 17/02/16 08:30, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> @@ -190,6 +191,71 @@ long arch_do_sysctl(
>> }
>> break;
>>
>> +case XEN_SYSCTL_get_cpu_featureset:
>> +{
>> +const uint32_t *featureset;
>> +unsigned int nr;
>> +
>> +/*
Wei Liu writes ("Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands"):
> On Tue, Feb 16, 2016 at 05:53:18PM +, Ian Jackson wrote:
> > I don't have a strong opinion, but I would lean towards insisting that
> > on command lines each setting should be in its own argument.
>
> We should suppor
>>> On 17.02.16 at 13:17, wrote:
> On 17/02/16 08:30, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> @@ -190,6 +191,71 @@ long arch_do_sysctl(
>>> }
>>> break;
>>>
>>> +case XEN_SYSCTL_get_cpu_featureset:
>>> +{
>>> +const uint32_t *featureset;
>>> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-2271 / XSA-170
version 3
VMX: guest user mode may crash guest with non-canonical RIP
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-2270 / XSA-154
version 3
x86: inconsistent cachability flags on guest mappings
UPDATES IN VERSION 3
Clarify cumbersome Resolution wording.
The p
On 2/17/2016 12:34 PM, Jan Beulich wrote:
The reason I need this is to pass '-save-temps' to GCC, I want to inspect
some code
and it would be easier to do that on the preprocessed files.
... there's absolutely no need to for a case like this, at least as
long as the xen/ subtree is where you w
flight 82859 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/82859/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 82574
test-armhf-armhf-xl-rtds
>>> On 17.02.16 at 13:09, wrote:
> On 2/17/2016 12:34 PM, Jan Beulich wrote:
>>
>>> The reason I need this is to pass '-save-temps' to GCC, I want to inspect
>>> some code
>>> and it would be easier to do that on the preprocessed files.
>> ... there's absolutely no need to for a case like this, at
> On February 16, 2016 7:06pm, wrote:
> >>> On 16.02.16 at 11:50, wrote:
> >> On February 11, 2016 at 1:01am, wrote:
> >> >>> On 05.02.16 at 11:18, wrote:
> >> > @@ -369,12 +376,16 @@ void iommu_share_p2m_table(struct domain*
> d)
> >> > ops->share_p2m(d);
> >> > }
> >> >
> >> > -v
>>> On 16.02.16 at 18:37, wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -787,25 +787,46 @@ typedef struct start_info start_info_t;
> /*
> * Start of day structure passed to PVH guests in %ebx.
> *
> - * NOTE: nothing will be loaded at physical address 0, so
> -
On 17/02/16 08:55, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> @@ -467,11 +420,8 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
>> regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
>> break;
>> case 1: /* leaf 1 */
>> -regs[0] &= (XSAVEOPT | XSAVEC
>>> On 17.02.16 at 13:49, wrote:
>> On February 16, 2016 7:06pm, wrote:
>> >>> On 16.02.16 at 11:50, wrote:
>> >> On February 11, 2016 at 1:01am, wrote:
>> >> >>> On 05.02.16 at 11:18, wrote:
>
>> >> > @@ -369,12 +376,16 @@ void iommu_share_p2m_table(struct domain*
>> d)
>> >> > o
On 17/02/16 09:02, Jan Beulich wrote:
On 08.02.16 at 18:26, wrote:
> This fiddles with behavior on AMD only, yet it's not obvious why this
> couldn't be done in vendor independent code (it should, afaict, be
> benign for Intel).
AMD and Intel levelling are fundamentally different.
The forme
The FPU exception state includes 4 registers:
- 64-bit FIP
- 16-bit FCS
- 64-bit FDP
- 16-bit FDS
When a CPU takes an FPU exception in long mode, all 4 registers are
fully updated. This state can be saved with a combination of REX.W
prefixed XSAVE and FNSTENV. This state cannot be restored with
On 12/02/16 16:27, Jan Beulich wrote:
On 05.02.16 at 14:41, wrote:
>> +/* Intel-defined CPU features, CPUID level 0x0001.edx, word 0 */
>> +#define X86_FEATURE_FPU ( 0*32+ 0) /* Onboard FPU */
> Regardless of you limiting the interface to tools only, I'm not
> convinced exposi
On 2/17/2016 2:43 PM, Jan Beulich wrote:
On 17.02.16 at 13:09, wrote:
On 2/17/2016 12:34 PM, Jan Beulich wrote:
The reason I need this is to pass '-save-temps' to GCC, I want to inspect
some code
and it would be easier to do that on the preprocessed files.
... there's absolutely no need to fo
On 12/02/16 17:14, Jan Beulich wrote:
On 12.02.16 at 17:48, wrote:
>> On 12/02/16 16:43, Jan Beulich wrote:
>> On 05.02.16 at 14:42, wrote:
--- /dev/null
+++ b/xen/arch/x86/cpuid.c
@@ -0,0 +1,19 @@
+#include
+#include
+
+const uint32_t known_features[
>>> On 17.02.16 at 14:03, wrote:
> On 17/02/16 08:55, Jan Beulich wrote:
> On 05.02.16 at 14:42, wrote:
>>> @@ -467,11 +420,8 @@ static void xc_cpuid_config_xsave(xc_interface *xch,
>>> regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
>>> break;
>>> case 1: /* leaf 1 */
>>> On 17.02.16 at 14:08, wrote:
> On 12/02/16 16:27, Jan Beulich wrote:
> On 05.02.16 at 14:41, wrote:
>>> +/* Intel-defined CPU features, CPUID level 0x0001.edx, word 0 */
>>> +#define X86_FEATURE_FPU ( 0*32+ 0) /* Onboard FPU */
>> Regardless of you limiting the interface t
>>> On 17.02.16 at 14:06, wrote:
> On 17/02/16 09:02, Jan Beulich wrote:
> On 08.02.16 at 18:26, wrote:
>> This fiddles with behavior on AMD only, yet it's not obvious why this
>> couldn't be done in vendor independent code (it should, afaict, be
>> benign for Intel).
>
> AMD and Intel level
> On February 17, 2016 9:05pm, wrote:
> >>> On 17.02.16 at 13:49, wrote:
> >> On February 16, 2016 7:06pm, wrote:
> >> >>> On 16.02.16 at 11:50, wrote:
> >> >> On February 11, 2016 at 1:01am, wrote:
> >> >> >>> On 05.02.16 at 11:18, wrote:
> >
> >> >> > @@ -369,12 +376,16 @@ void iommu_shar
>>> On 17.02.16 at 14:08, wrote:
> The FPU exception state includes 4 registers:
>
> - 64-bit FIP
> - 16-bit FCS
> - 64-bit FDP
> - 16-bit FDS
>
> When a CPU takes an FPU exception in long mode, all 4 registers are
> fully updated. This state can be saved with a combination of REX.W
> prefixed
>>> On 17.02.16 at 14:11, wrote:
> On 2/17/2016 2:43 PM, Jan Beulich wrote:
> On 17.02.16 at 13:09, wrote:
>>> On 2/17/2016 12:34 PM, Jan Beulich wrote:
> The reason I need this is to pass '-save-temps' to GCC, I want to inspect
> some code
> and it would be easier to do that on t
On Tue, Feb 16, 2016 at 01:55:33PM +0100, Juergen Gross wrote:
> Hi Daniel,
>
> On 16/02/16 12:35, Daniel Kiper wrote:
> > Hey Juergen,
[...]
> > After that I decided to take a look at Linux kernel upstream. I saw
> > that xen_max_p2m_pfn in xen_build_mfn_list_list() is equal to "the
> > end of l
On 17/02/16 10:55, Jan Beulich wrote:
On 17.02.16 at 11:43, wrote:
>> On 16/02/16 10:06, Jan Beulich wrote:
>> On 15.02.16 at 18:12, wrote:
On 15/02/16 15:43, Jan Beulich wrote:
On 05.02.16 at 14:42, wrote:
>> @@ -4617,50 +4618,39 @@ void hvm_cpuid(unsigned int input,
>>> On 05.02.16 at 11:18, wrote:
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -45,6 +45,8 @@ void do_suspend_lowlevel(void);
>
> static int device_power_down(void)
> {
> +int rc;
> +
> console_suspend();
>
> time_suspend();
> @@ -53,7 +55,9 @@ static
CID: 1055898
Signed-off-by: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index d5a397a..e819ee6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2795,6 +2795,7 @@ static
Using bare realloc risks leaking the old pointer if the realloc fails.
Since xrealloc exits on such failures, drop the error handling.
Noticed while fixing, but not related to, CID 1055898.
Signed-off-by: Ian Campbell
---
tools/libxl/xl_cmdimpl.c | 6 +-
1 file changed, 1 insertion(+), 5 d
Currently the fd is opened and then later closed and
restore_fd_to_close set back to -1, however there are several goto out
and goto error_out paths in the interim.
Since the code resets restore_fd_to_close to -1 it is OK to check this
and close on the out path too.
CID: 1055897
Signed-off-by: I
>>> On 05.02.16 at 11:18, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -968,6 +968,13 @@ Use this to work around firmware issues providing
> correct RMRR entries. Rather
> than only mapping RAM pages for IOMMU accesses for Dom0, with this op
>>> On 05.02.16 at 11:18, wrote:
(Side note: The VT-d: prefix of the subject seems inadequate here.)
> to pass down a flag indicating whether the lock is being held.
"the lock" being which one?
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1100,7 +1100,7 @@ tlbflush:
> if (
1 - 100 of 248 matches
Mail list logo
