[Xen-devel] [PATCH] x86emul: LOCK check adjustments

BT, being encoded as DstBitBase just like BT{C,R,S}, nevertheless does not write its (register or memory) operand and hence also doesn't allow a LOCK prefix to be used. At the same time CLAC/STAC have no need to explicitly check lock_prefix - this is being taken care of by generic code.

[Xen-devel] [xen-4.8-testing test] 104298: tolerable FAIL - PUSHED

flight 104298 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/104298/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-credit2 15 guest-start/debian.repeatfail like 104267

Re: [Xen-devel] [PATCH] x86/emul: Corrections to cmpxchg{8, 16}b emulation (to fix 32bit PV guests)

>>> On 20.01.17 at 09:52, wrote: > @@ -2852,6 +2852,11 @@ x86_emulate( > else if ( !(d & Mov) ) /* optimisation - avoid slow emulated read */ > { > fail_if(lock_prefix ? !ops->cmpxchg : !ops->write); > + > +/* cmpxchg{8,16}b

[Xen-devel] [PATCH] docs: clarify xl mem-max semantics

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.

Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms

>>> On 20.01.17 at 02:34, wrote: > @@ -100,20 +107,48 @@ multiboot2_header_start: > gdt_boot_descr: > .word 6*8-1 > .long sym_phys(trampoline_gdt) > +.long 0 /* Needed for 64-bit lgdt */ > + > +.align 4 > +vga_text_buffer: > +

Re: [Xen-devel] [PATCH RESEND v5 01/24] docs: create L2 Cache Allocation Technology (CAT) feature document

> From: Yi Sun > Sent: Thursday, January 19, 2017 2:01 PM > > This patch creates L2 CAT feature document in doc/features/. > It describes details of L2 CAT. A good write-up, but still some improvements required. :-) > > Signed-off-by: Yi Sun > --- >

[Xen-devel] memory hotplug for domUs

Recently Jim asked me why he can use "xl mem-max" to raise the allowed memory size of a domain in the hypervisor above the configured maxmem limit of the domain, but not use "xl mem-set" to balloon the domain up to this value later. I thought libxl_domain_setmaxmem() being buggy as it doesn't

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

On January 16, 2017 1:26 PM, Tian, Kevin wrote: >I cannot come up a valid reason for such situation (intack.vector is 0x30 while >pt_vector is 0x38 from Chao's data). pt_update_irq is invoked before checking >highest pending IRRs so pt_vector should be honored anyway. >One possible reason is that

[Xen-devel] [ovmf test] 104306: all pass - PUSHED

flight 104306 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104306/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 19ca06bb84cafd661f7da34e9ca3c7ec6add1135 baseline version: ovmf

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

>>> On 20.01.17 at 09:47, wrote: > Jan, I can't follow vector classes.. could you explain more? Thanks.. For determining vector priority, the LAPIC uses only the high 4 bits. Iirc this is well documented in the SDM. Jan ___

[Xen-devel] [PATCH] x86/emul: Corrections to cmpxchg{8, 16}b emulation (to fix 32bit PV guests)

c/s ff913f6 "x86/PV: restrict permitted instructions during memory write emulation" added an x86_insn_is_mem_write() restriction to all PV instructions which trap for emulation because of read-only mappings (pagetables, mmcfg and msi-x intercepts). Because of the way cmpxchg{8,16}b was decoded

Re: [Xen-devel] [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB

>>> On 20.01.17 at 05:06, wrote: > On 1/19/17 8:34 PM, Daniel Kiper wrote: >> Subsequent patches introducing relocatable early boot code play with >> page tables using 2 MiB huge pages. If load address is not aligned at >> 2 MiB then code touching such page tables must have

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

On January 18, 2017 5:38 PM, Jan Beulich wrote: On 18.01.17 at 05:57, wrote: >> Attached was my earlier comment: >> >> -- >>> >>> On 20.12.16 at 06:37, wrote: >>> >> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com] >>> >> Sent: Friday, December

Re: [Xen-devel] [PATCH 1/1] kexec: ensure kexec_status() return bit value of 0 or 1

>>> On 19.01.17 at 18:10, wrote: > --- a/xen/common/kexec.c > +++ b/xen/common/kexec.c > @@ -1182,7 +1182,8 @@ static int kexec_status(XEN_GUEST_HANDLE_PARAM(void) > uarg) > if ( kexec_load_get_bits(status.type, , ) ) > return -EINVAL; > > -return

Re: [Xen-devel] [PATCH v13 3/3] iommu: add rmrr Xen command line option for extra rmrrs

>>> On 19.01.17 at 18:44, wrote: > On Thu, Jan 19, 2017 at 01:29:15AM -0700, Jan Beulich wrote: >> >>> On 18.01.17 at 20:56, wrote: >> > I am looking at rmrr_identity_mapping where the RMRR paddr get converted >> > to pfn and then mapped

[Xen-devel] [PATCH v2] x86: segment attribute handling adjustments

Null selector loads into SS (possible in 64-bit mode only, and only in rings other than ring 3) must not alter SS.DPL. (This was found to be an issue on KVM, and fixed in Linux commit 33ab91103b.) Further arch_set_info_hvm_guest() didn't make sure that the ASSERT()s in hvm_set_segment_register()

[Xen-devel] [PATCH] x86emul: CMPXCHG{8,16}B are memory writes

This fixes a regression introduced by commit ff913f68c9 ("x86/PV: restrict permitted instructions during memory write emulation") breaking namely 32-bit PV guests (which commonly use CMPXCHG8B for certain page table updates). Reported-by: Andrew Cooper Signed-off-by:

<    1   2   3