>>> On 21.12.16 at 06:44, wrote:
> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -315,9 +315,13 @@ void vmx_intr_assist(void)
> * Set eoi_exit_bitmap for periodic timer interrup to cause
> EOI-induced VM
> * exit, then pending periodic time interrups
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
Changes since initial:
* DRM changed to DISPL, protocol made generic
* major re-work addressing issues raised for sndif
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Gryts
From: Oleksandr Andrushchenko
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 to extend:
o multiple dynamically allocated/destroyed framebuffers
o buf
flight 103786 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-bootfail REGR. vs. 101675
test-amd64-amd64-xl-
>>> On 21.12.16 at 17:32, wrote:
> The bracketing of x86_emulate() calling the ops->vmfunc() hook is wrong with
> respect to the assignment to rc, which can trip the new assertions in
> x86_emulate_wrapper().
>
> The hvmemul_vmfunc() hook should only raise #UD if X86EMUL_EXCEPTION is
> returned.
>>> On 21.12.16 at 17:32, wrote:
> vmfunc can in principle modify register state, so should operate on the shadow
> register state rather than the starting state of emulation.
>
> Signed-off-by: Andrew Cooper
While in principle this is fine, I'd rather see the register state
constified for now,
Patch 1 effectively is an alternative proposal to
https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg02567.html
1: x86/HVM: constify VMFUNC emulation hook
2: x86/VMX: don't needlessly install VMFUNC emulation hook
Signed-off-by: Jan Beulich
>>> On 21.12.16 at 22:07, wrote:
> @@ -99,20 +100,23 @@ static void decision_tree(
> decision_tree(s, (s+e)/2, var, leaf);
> pop_block();
> }
> +#endif
>
> static struct option options[] = {
> { "maxcpu", 1, 0, 'c' },
> +#if defined(CONFIG_X86)
> { "dm-version", 1, 0, 'q' }
... to clarify that the register state does not get altered (behind the
back of the emulator).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2006,7 +2006,7 @@ static void vmx_vcpu_update_vmfunc_ve(st
vmx_vmcs_exit(v);
}
-static int vmx_v
Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
determine whether to install the hook in the first place.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2011,7 +2011,7 @@ static int vmx_vcpu_emulate_vmfunc(const
int rc = X8
>>> On 20.12.16 at 20:46, wrote:
> Signed-off-by: Alistair Francis
Without some rationale given I don't think such changes are
acceptable at all. And then, as already pointed out others, the
use of -Werror is there not just for fun. If anything I think an
override to that default could be accept
>>> On 20.12.16 at 20:46, wrote:
> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -35,6 +35,9 @@ UTIL_LIBS = -lutil
> SONAME_LDFLAG = -soname
> SHLIB_LDFLAGS = -shared
>
> +# Allow users to add extra CFLAGS
> +CFLAGS += $(EXTRA_CFLAGS)
Along the lines of Wei's reply - please remember th
>>> On 21.12.16 at 17:44, wrote:
> The lto symbol is superseded by CONFIG_LTO now.
Considering that this affects both tools and hypervisor build - is that
true for both? Or if it's always been meant for the hypervisor build
only, should is perhaps move out of config/ at once?
Jan
_
>>> On 21.12.16 at 17:44, wrote:
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 21.12.16 at 17:44, wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -19,7 +19,6 @@ or = $(if $(strip $(1)),$(1),$(if $(strip
> $(2)),$(2),$(if $(strip $(3)),$(
> # A debug build of tools?
> # Hypervisor debug build is controlled by Kconfig.
> debug ?= y
> -debug_symbols ?= $(debug)
flight 103790 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 3 host-install(3)broken REGR. vs. 103769
test-amd64-amd6
flight 103788 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 3 host-install(3)broken REGR. vs. 103466
test-amd64-i386-li
On 12/12/16 15:35, Ross Lagerwall wrote:
> When relocating the p2m, take special care not to relocate it so
> that is overlaps with the current location of the p2m/initrd. This is
> needed since the full extent of the current location is not marked as a
> reserved region in the e820.
>
> This was
On 20/12/16 15:02, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang
Committed to xen/tip.git for-linus-4.10
Juergen
> ---
> drivers/xen/evtchn.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 delet
Make select loop more readable.
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_qmp.c | 123
1 file changed, 61 insertions(+), 62 deletions(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ad22ad4..123a6bf 100644
--- a/tool
On Thu, Dec 22, 2016 at 03:48:48PM +0800, Tian, Kevin wrote:
>sent too quick. I meant please add your tested-by here. :-)
Yes, of course. Tested-by: Chao Gao
>
>> From: Tian, Kevin
>> Sent: Thursday, December 22, 2016 3:48 PM
>>
>> Thanks a lot!
>>
>> > From: Gao, Chao
>> > Sent: Thursday, Dec
On Thu, Dec 22, 2016 at 01:48:41AM -0700, Jan Beulich wrote:
> >>> On 21.12.16 at 17:44, wrote:
> > The lto symbol is superseded by CONFIG_LTO now.
>
> Considering that this affects both tools and hypervisor build - is that
> true for both? Or if it's always been meant for the hypervisor build
>
osstest service owner writes ("[xen-unstable test] 103788: regressions -
trouble: broken/fail/pass"):
> flight 103788 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/103788/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which
This run is configured for baseline tests only.
flight 68256 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-
On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> >>> On 21.12.16 at 17:32, wrote:
> > On Mon, Dec 12, 2016 at 06:56:36AM -0700, Jan Beulich wrote:
> >> >>> On 30.11.16 at 17:49, wrote:
> >> > +static int __init hvm_setup_acpi_madt(struct domain *d, paddr_t *addr)
> >> > +{
> >> > +
>>> On 22.12.16 at 11:28, wrote:
> osstest service owner writes ("[xen-unstable test] 103788: regressions -
> trouble: broken/fail/pass"):
>> flight 103788 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/103788/
>>
>> Regressions :-(
>>
>> Tests which did not succe
Also CC Anthony, who wrote the original code.
On Thu, Dec 22, 2016 at 05:53:07PM +0800, Zhang Chen wrote:
> Make select loop more readable.
The behaviour of this function is changed. The changes are not
necessarily wrong, but we need to have clear commit message for why the
change of behaviour is
On Wed, Dec 21, 2016 at 04:39:22PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 21, 2016 at 01:37:31PM -0800, Eric DeVolder wrote:
> > Fix cut-n-paste typo; changed the words "count not" to "could not".
> >
> > No functional changes
> >
> > Signed-off-by: Eric DeVolder
>
> Reviewed-by: Kon
On Wed, Dec 21, 2016 at 04:53:52PM +, Wei Liu wrote:
> On Wed, Dec 21, 2016 at 04:47:26PM +, Roger Pau Monne wrote:
> > It should be rc_pid.
> >
> > Signed-off-by: Roger Pau Monné
> > Reported-by: Nathan Friess
>
> Acked + applied.
>
> I suspect all the patches to fix FreeBSD init scri
On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote:
> To avoid build errors related to missing file 'sys/sysctl.h' by removing
> the #include statement.
>
> Signed-off-by: Alistair Francis
I can find this in Linux. Maybe this is also due to the libc you're
using?
On the flip side,
Roger Pau Monne writes ("Re: [PATCH] init/FreeBSD: fix incorrect usage of
$rc_pids in xendriverdomain"):
> On Wed, Dec 21, 2016 at 04:53:52PM +, Wei Liu wrote:
> > I suspect all the patches to fix FreeBSD init script should be
> > backported?
>
> Yes, that would be nice. I plan to apply them
>>> On 22.12.16 at 11:43, wrote:
> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
>> I'm not convinced these table entries are tied to >255 CPUs - I'm
>> seeing them on systems with far less. Hence I simply wonder what
>> functionality we may miss to offer to OSes with these tables
>
>>> On 19.09.16 at 07:52, wrote:
> Since vlapic_init() is called before vcpu_initialise().
> We should also follow the same order here.
s/same/inverse/?
Also the ordering issue extends to other calls, and I think if at all
possible we should then do all the teardown in reverse order of
init.
Ja
>>> On 19.09.16 at 07:52, wrote:
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -328,14 +328,15 @@ typedef union __packed
> struct
> {
> u64 tpr: 8;
> -u64 irq: 1;
> +u64 irq: 1; /* disabled
On Tue, Dec 20, 2016 at 11:46:55AM -0800, Alistair Francis wrote:
> tools/blktap2/vhd: Remove unused struct stat stats
> tools/blktap2: Fix missing header file
I've pushed these two to staging.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
>>> On 19.09.16 at 07:52, wrote:
> +int svm_avic_init_vcpu(struct vcpu *v)
> +{
> +struct vlapic *vlapic = vcpu_vlapic(v);
> +struct arch_svm_struct *s = &v->arch.hvm_svm;
> +
> +if ( svm_avic )
> +s->avic_bk_pg = vlapic->regs_page;
Why this copying? Can't consuming code not u
On Thu, Dec 22, 2016 at 01:51:28AM -0700, Jan Beulich wrote:
> >>> On 21.12.16 at 17:44, wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -19,7 +19,6 @@ or = $(if $(strip $(1)),$(1),$(if $(strip
> > $(2)),$(2),$(if $(strip $(3)),$(
> > # A debug build of tools?
> > # Hypervisor debug
>>> On 19.09.16 at 07:52, wrote:
> +void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs *regs)
> +{
> +struct vcpu *v = current;
Please name such variables "curr", which at once avoids the need for
the unusual name ...
> +struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
> +u32 ic
>>> On 19.09.16 at 07:52, wrote:
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -45,6 +45,83 @@ avic_get_phy_ait_entry(struct vcpu *v, int index)
> }
>
> /***
> + * AVIC VCPU SCHEDULING
> + */
> +static v
>>> On 19.09.16 at 07:52, wrote:
> Also, the AVIC hardware automatically synchronizes TPR and CR8/vTPR, when
> values are updated. Therefore, xen does not need to handle this when enable
> AVIC.
I'm having trouble matching this up with ...
> --- a/xen/arch/x86/hvm/svm/vmcb.c
> +++ b/xen/arch/x86
>>> On 19.09.16 at 07:52, wrote:
> Suravee Suthikulpanit (9):
> x86/HVM: Introduce struct hvm_pi_ops
> x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as
> non-static
> x86/HVM: Call vlapic_destroy after vcpu_destroy
> x86/SVM: Modify VMCB fields to add AVIC support
>
>>> On 19.09.16 at 07:52, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1495,6 +1495,16 @@ const struct hvm_function_table * __init
> start_svm(void)
> svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
> ((cpuid_edx(0x8001) & 0x04
On 22/12/16 10:45, Jan Beulich wrote:
On 22.12.16 at 11:28, wrote:
osstest service owner writes ("[xen-unstable test] 103788: regressions -
trouble: broken/fail/pass"):
flight 103788 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103788/
Regressions :-(
Tests which
On 22/12/16 02:15, Stefano Stabellini wrote:
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 467333c..fde5b32 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -72,6 +72,8 @@ struct pending_irq
#define GIC_INVALID_LR (uint8_t)~0
>>> On 10.10.16 at 02:32, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/pmem.c
I wonder whether this should really be x86-specific: It's all ACPI
based, isn't it? I notice that you already place pmem.h that way.
> +static int is_included(unsigned long s1, unsigned long e1,
> +
flight 103791 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 3 host-install/src_host(3) broken REGR. vs. 103770
test-amd64-amd
While working on the Linux xenbus kernel driver I stumbled over a rather
strange interface: a Xenstore watch event is delivered via a callback
defined as:
void (*callback)(struct xenbus_watch *,
const char **vec, unsigned int len);
vec is an array of strings and len the n
flight 103804 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103804/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote:
> >>> On 22.12.16 at 11:43, wrote:
> > On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> >> > Since Xen is the one that sets the local APIC address in the MADT, and it
> >> > always matches the position of the emulated local
>>> On 10.10.16 at 02:32, wrote:
> +static int pmem_assign_pages(struct domain *d,
> + struct page_info *pg, unsigned int order)
What is the order parameter good for here, when the only caller
passes zero?
> +{
> +int rc = 0;
> +unsigned long i;
> +
> +spi
Andrew Cooper writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test]
103788: regressions - trouble: broken/fail/pass)"):
> No. No similar problems I am aware of anywhere in XenRT (which haven't
> ended up being down to human intervention in the firmware)
Indeed. I asked some XenRT folk
Juergen Gross writes ("Xenstore watch interface in the kernel"):
> While working on the Linux xenbus kernel driver I stumbled over a rather
> strange interface: a Xenstore watch event is delivered via a callback
> defined as:
>
> void (*callback)(struct xenbus_watch *,
> c
>>> On 10.10.16 at 02:32, wrote:
> --- a/xen/arch/x86/pmem.c
> +++ b/xen/arch/x86/pmem.c
> @@ -282,3 +282,44 @@ int pmem_populate(struct xen_pmemmap_args *args)
> args->nr_done = i;
> return rc;
> }
> +
> +static int pmem_teardown_preemptible(struct domain *d, int *preempted)
> +{
> +
>>> On 22.12.16 at 13:19, wrote:
> Perhaps it would be worth telling Xen not to reboot on crash...
I think that's worth giving a try (I assume that some timeout will cause
the machine to get rebooted at some point anyway, to make it available
again).
Jan
___
On 22/12/16 12:19, Ian Jackson wrote:
Andrew Cooper writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test] 103788:
regressions - trouble: broken/fail/pass)"):
No. No similar problems I am aware of anywhere in XenRT (which haven't
ended up being down to human intervention in the firmwar
On 22/12/16 08:27, Jan Beulich wrote:
On 21.12.16 at 17:32, wrote:
vmfunc can in principle modify register state, so should operate on the shadow
register state rather than the starting state of emulation.
Signed-off-by: Andrew Cooper
While in principle this is fine, I'd rather see the regis
Thursday, December 22, 2016, 1:22:06 PM, you wrote:
> Juergen Gross writes ("Xenstore watch interface in the kernel"):
>> While working on the Linux xenbus kernel driver I stumbled over a rather
>> strange interface: a Xenstore watch event is delivered via a callback
>> defined as:
>>
>> void (*
On 22/12/16 13:49, Sander Eikelenboom wrote:
>
> Thursday, December 22, 2016, 1:22:06 PM, you wrote:
>
>> Juergen Gross writes ("Xenstore watch interface in the kernel"):
>>> While working on the Linux xenbus kernel driver I stumbled over a rather
>>> strange interface: a Xenstore watch event is
On December 22, 2016 2:21:26 AM EST, Oleksandr Andrushchenko
wrote:
>Hi, Konrad!
>
>I see no comments for almost 3 weeks now, so
>probably there are no objections against this protocol.
>Can we please move on on this?
Sorry, I had been busy with internal high priority items. Let me take a look a
On 22/12/16 12:59, Juergen Gross wrote:
On 22/12/16 13:49, Sander Eikelenboom wrote:
Thursday, December 22, 2016, 1:22:06 PM, you wrote:
Juergen Gross writes ("Xenstore watch interface in the kernel"):
While working on the Linux xenbus kernel driver I stumbled over a rather
strange interface:
On 22/12/16 08:36, Jan Beulich wrote:
... to clarify that the register state does not get altered (behind the
back of the emulator).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://l
On 22/12/16 08:37, Jan Beulich wrote:
Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
determine whether to install the hook in the first place.
Signed-off-by: Jan Beulich
I am not so sure about this.
vmfunc is reachable in the instruction emulator on hardware which
doesn't
Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test]
103788: regressions - trouble: broken/fail/pass)"):
> On 22.12.16 at 13:19, wrote:
> > Perhaps it would be worth telling Xen not to reboot on crash...
>
> I think that's worth giving a try (I assume that some timeout will
Sander Eikelenboom writes ("Re: [Xen-devel] Xenstore watch interface in the
kernel"):
> Something I did ran into while trying to use xenstore, was that the
> callbacks don't give back the previous and current value.
Others have replied to this, and I agree with them, but: this makes me
think you
On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> A linker table is a data structure that is stitched together from
> items
> in multiple object files. Linux has historically implicitly used
> linker
> tables for ages, however they were all built in an adhoc manner which
> requires link
On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote:
> Move the __jump_table from the a custom section solution
> to a generic solution, this avoiding extra vmlinux.lds.h
> customizations.
>
> This also demos the use of the .data linker table and of
> the shared asm call push_section_tbl().
flight 103792 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103792/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-13 host-install(3)broken REGR. vs. 10
>>> On 22.12.16 at 14:47, wrote:
> On 22/12/16 08:37, Jan Beulich wrote:
>> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
>> determine whether to install the hook in the first place.
>>
>> Signed-off-by: Jan Beulich
>
> I am not so sure about this.
>
> vmfunc is reachable in
flight 68259 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68259/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 68223
jobs:
build-amd64 pass
build-armh
flight 103806 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103806/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 07.12.16 at 16:57, wrote:
> efi/buildid.o: file not recognized: File format is ambiguous
> efi/buildid.o: matching formats: coff-x86-64 pe-x86-64
Just fyi: After some analysis of the binutils sources I have come to
the conclusion that this needs help from the binutils folks. I've
>>> On 22.12.16 at 14:47, wrote:
> Jan Beulich writes ("Re: [Xen-devel] elbling1 (was Re: [xen-unstable test]
> 103788: regressions - trouble: broken/fail/pass)"):
>> On 22.12.16 at 13:19, wrote:
>> > Perhaps it would be worth telling Xen not to reboot on crash...
>>
>> I think that's worth giv
>>> On 22.12.16 at 15:31, wrote:
On 22.12.16 at 14:47, wrote:
>> On 22/12/16 08:37, Jan Beulich wrote:
>>> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
>>> determine whether to install the hook in the first place.
>>>
>>> Signed-off-by: Jan Beulich
>>
>> I am not so su
"x86emul: in_longmode() should not ignore ->read_msr() errors" aka
c/s 122dd9575c7a introduced a use of unlikely() in
xen/arch/x86/x86_emulate/x86_emulate.c.
I think this is probably intentional and fine. However, there is no
definition of unlikely in the x86 emulator test harness, under tools.
On 22/12/16 14:58, Ian Jackson wrote:
"x86emul: in_longmode() should not ignore ->read_msr() errors" aka
c/s 122dd9575c7a introduced a use of unlikely() in
xen/arch/x86/x86_emulate/x86_emulate.c.
I think this is probably intentional and fine. However, there is no
definition of unlikely in the x
Signed-off-by: Ian Jackson
CC: Jan Beulich
---
docs/misc/xen-command-line.markdown | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 0138978..68c81e6 100644
--- a/docs/misc/xen-command-line.mar
On 22/12/16 14:58, Jan Beulich wrote:
On 22.12.16 at 15:31, wrote:
On 22.12.16 at 14:47, wrote:
On 22/12/16 08:37, Jan Beulich wrote:
Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
determine whether to install the hook in the first place.
Signed-off-by: Jan Beulich
I am
Andrew Cooper writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in
x86 emulator test harness"):
> On 22/12/16 14:58, Ian Jackson wrote:
> > "x86emul: in_longmode() should not ignore ->read_msr() errors" aka
> > c/s 122dd9575c7a introduced a use of unlikely() in
> > xen/arch/x86/x86_em
Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package.
---
Eventually this patch will contain the actual bindings package; for
now it just includes a stub package.
To Do:
- Have configure detect golang bindings properly
CC: xen-devel
CC: Ian Jackson
>>> On 22.12.16 at 16:10, wrote:
> I did not find this important build fix for a regression in 4.8.0
> because:
I wonder why you consider this important - the harness doesn't
get built by default, and is of little use for other than smoke
testing a limited set of changes to the insn emulator.
>
On 12/20/16 3:37 AM, Anshul Makkar wrote:
> On 20/12/2016 04:03, Doug Goldstein wrote:
>> On 12/19/16 10:02 AM, Doug Goldstein wrote:
>>> On 12/14/16 3:09 PM, Daniel De Graaf wrote:
On 12/12/2016 09:00 AM, Anshul Makkar wrote:
> During guest migrate allow permission to prevent
> spurio
>>> On 22.12.16 at 16:02, wrote:
> @@ -1356,7 +1357,9 @@ The following resources are available:
>
> > Default: `0`
>
> -Specify the host reboot method.
> +Specify the host reboot method,
> +used when Xen crashes.
> +(This does not affect deliberate reboots initiated by dom0.)
This should be
>>> On 22.12.16 at 16:28, wrote:
> On 12/20/16 3:37 AM, Anshul Makkar wrote:
>> On 20/12/2016 04:03, Doug Goldstein wrote:
>>> On 12/19/16 10:02 AM, Doug Goldstein wrote:
On 12/14/16 3:09 PM, Daniel De Graaf wrote:
> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>> During guest migrate
>>> On 22.12.16 at 16:14, wrote:
> On 22/12/16 14:58, Jan Beulich wrote:
> On 22.12.16 at 15:31, wrote:
>> On 22.12.16 at 14:47, wrote:
On 22/12/16 08:37, Jan Beulich wrote:
> Instead of checking cpu_has_vmx_vmfunc inside the hook, use it to
> determine whether to install th
On 12/22/2016 02:19 AM, Juergen Gross wrote:
> When accessing Xenstore in a transaction the user is specifying a
> transaction id which he normally obtained from Xenstore when starting
> the transaction. Xenstore is validating a transaction id against all
> known transaction ids of the connection t
On Thu, Dec 22, 2016 at 2:54 AM, Wei Liu wrote:
> On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote:
>> To avoid build errors related to missing file 'sys/sysctl.h' by removing
>> the #include statement.
>>
>> Signed-off-by: Alistair Francis
>
> I can find this in Linux. Maybe this
On 12/20/16 1:47 PM, Alistair Francis wrote:
> To avoid build errors related to missing file 'sys/sysctl.h' by removing
> the #include statement.
>
> Signed-off-by: Alistair Francis
> ---
> tools/blktap2/drivers/block-remus.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tools/blktap2
On 12/22/2016 02:19 AM, Juergen Gross wrote:
> When the xenbus driver does some special handling for a Xenstore
> command any error condition related to the command should be returned
> via an error response instead of letting the related write operation
> fail. Otherwise the user land handler migh
On 12/22/2016 02:19 AM, Juergen Gross wrote:
> In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of
> xs_input_avail(). Remove it.
>
> Signed-off-by: Juergen Gross
>
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@li
On 22/12/16 16:38, Boris Ostrovsky wrote:
> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>> When accessing Xenstore in a transaction the user is specifying a
>> transaction id which he normally obtained from Xenstore when starting
>> the transaction. Xenstore is validating a transaction id against
On 22/12/16 16:49, Boris Ostrovsky wrote:
> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>> When the xenbus driver does some special handling for a Xenstore
>> command any error condition related to the command should be returned
>> via an error response instead of letting the related write operati
On 12/22/2016 10:55 AM, Juergen Gross wrote:
> On 22/12/16 16:49, Boris Ostrovsky wrote:
>> On 12/22/2016 02:19 AM, Juergen Gross wrote:
>>> When the xenbus driver does some special handling for a Xenstore
>>> command any error condition related to the command should be returned
>>> via an error re
>>> On 14.12.16 at 05:07, wrote:
> The current cache allocation codes in psr.c do not consider
> future features addition and are not friendly to extend.
>
> To make psr.c be more flexible to add new features and fulfill
> the program principle, open for extension but closed for
> modification, w
On 12/20/2016 12:42 PM, Jan Beulich wrote:
> This is in preparation of eliminating the mis-naming of 64-bit fields
> with 32-bit register names (eflags instead of rflags etc).
>
> Signed-off-by: Jan Beulich
Acked-by: Razvan Cojocaru
Thanks,
Razvan
>>> On 14.12.16 at 05:07, wrote:
> To construct an extendible framework, we need analyze PSR features
> and abstract the common things and feature specific things. Then,
> encapsulate them into different data structures.
>
> By analyzing PSR features, we can get below map.
> +
On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote:
> On 22.12.16 at 11:43, wrote:
>>> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> Since Xen is the one that sets the local APIC address in the MADT, and it
> al
>>> On 22.12.16 at 17:17, wrote:
> On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
>> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
>
> Why would Xen need to be able to parse the AML that is intended to be
> executed by dom0? I'd think that all the hypervisor would need to do is
flight 103808 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103808/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> >>> On 22.12.16 at 17:17, wrote:
> > On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
> >
> > Why would Xen need to be able to parse the AML that is intended to be
>
Jan Beulich writes ("Re: [PATCH] tools/tests/x86_emulate: #define unlikely in
x86 emulator test harness"):
> On 22.12.16 at 16:10, wrote:
> > I did not find this important build fix for a regression in 4.8.0
> > because:
>
> I wonder why you consider this important - the harness doesn't
> get bu
1 - 100 of 156 matches
Mail list logo
