Re: [Xen-devel] [PATCH v2 1/2] build: move debug{, _symbols} to tools/Rules.mk

>>> On 23.12.16 at 13:24, wrote: > 31d41d7b tried to make debug affect tools build only but failed to take > care of debug_symbols (which appends "-g" to CFLAGS). > > Move both to tools/Rules.mk at once in this patch. > > Signed-off-by: Wei Liu

Re: [Xen-devel] [PATCH v4 03/24] x86: refactor psr: implement main data structures.

On 17-01-03 02:12:53, Jan Beulich wrote: > >>> On 03.01.17 at 09:49, wrote: > > On 17-01-03 01:00:37, Jan Beulich wrote: > >> >>> On 26.12.16 at 07:56, wrote: > >> > On 16-12-22 09:13:43, Jan Beulich wrote: > >> >> >>> On 14.12.16 at 05:07,

[Xen-devel] [libvirt test] 104021: regressions - FAIL

flight 104021 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/104021/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 9 debian-di-installfail REGR. vs. 104005 Regressions which are

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

>>> On 03.01.17 at 09:15, wrote: > >>-Original Message- >>From: Jan Beulich [mailto:jbeul...@suse.com] >>Sent: Tuesday, January 03, 2017 3:35 PM >>To: Xuquan (Quan Xu) >>Cc: Andrew Cooper; George Dunlap; yang.zhang...@gmail.com; Chao Gao; >>Jun Nakajima; Kevin Tian;

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

>>> On 28.12.16 at 19:22, wrote: > Now, we have two hypercalls XEN_DOMCTL_memory_mapping and > XENMEM_add_to_physmap_range having two distinct behavior when mapping an > MMIO into a guest. > > We should at least return an error, even if DOM0 decides to ignore it. > > I

Re: [Xen-devel] [PATCH v4 03/24] x86: refactor psr: implement main data structures.

On 17-01-03 01:00:37, Jan Beulich wrote: > >>> On 26.12.16 at 07:56, wrote: > > On 16-12-22 09:13:43, Jan Beulich wrote: > >> >>> On 14.12.16 at 05:07, wrote: > >> > If Dom2 has same CBM values, it can reuse these registers which COS_ID=1. > >>

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

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

[Xen-devel] [PATCH 1/2] x86/cpu: Drop unused X86_VENDOR_* values

Xen only has CPU drivers for Intel, Centaur and AMD. All other contributions to X86_VENDOR_NUM simply make the cpu_devs[] array longer, reducing the efficiency of get_cpu_vendor() There is one remaning hidden reference to X86_VENDOR_CYRIX in the MTRR code. However, as far as I can tell, Cyrix

Re: [Xen-devel] [PATCH 1/2] x86/cpu: Drop unused X86_VENDOR_* values

>>> On 03.01.17 at 13:06, wrote: > Xen only has CPU drivers for Intel, Centaur and AMD. All other contributions > to X86_VENDOR_NUM simply make the cpu_devs[] array longer, reducing the > efficiency of get_cpu_vendor() > > There is one remaning hidden reference to

Re: [Xen-devel] [PATCH v2 2/2] build: use debug_symbols to add -g3

>>> On 23.12.16 at 13:24, wrote: > @@ -146,7 +146,7 @@ SHLIB_libxenvchan = $(SHDEPS_libxenvchan) > -Wl,-rpath-link=$(XEN_LIBVCHAN) > > ifeq ($(debug),y) > # Disable optimizations and enable debugging information for macros > -CFLAGS += -O0 -g3 -fno-omit-frame-pointer >

Re: [Xen-devel] [PATCH v4 03/24] x86: refactor psr: implement main data structures.

>>> On 03.01.17 at 11:28, wrote: > Do you have any comment to other patches? Well, I'll get to them as time permits. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86/vvmx: Drop sreg_to_index[]

Since c/s 0888d36b "x86/emul: Correct the decoding of SReg3 operands", x86_seg_* have followed hardware encodings, meaning that this translation table is now an identiy transform. No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

Re: [Xen-devel] [PATCH v4 03/24] x86: refactor psr: implement main data structures.

>>> On 26.12.16 at 07:56, wrote: > On 16-12-22 09:13:43, Jan Beulich wrote: >> >>> On 14.12.16 at 05:07, wrote: >> > So, we need define a socket info data structure, 'struct >> > psr_socket_info' to manage information per socket. It contains a

Re: [Xen-devel] [PATCH v4 03/24] x86: refactor psr: implement main data structures.

>>> On 03.01.17 at 09:49, wrote: > On 17-01-03 01:00:37, Jan Beulich wrote: >> >>> On 26.12.16 at 07:56, wrote: >> > On 16-12-22 09:13:43, Jan Beulich wrote: >> >> >>> On 14.12.16 at 05:07, wrote: >> >> > +struct

Re: [Xen-devel] Stale Xenstore entries after start of domU with stubdom

Juergen Gross writes ("Stale Xenstore entries after start of domU with stubdom"): > Anyone an idea why I have additional stale Xenstore entries each time > I've started a new domU with a stubdom? After 4 such starts I have: > > vm = "" > -0100--fd7f-489bdb5a = "" > memory =

[Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

Comparing 3 integers is more efficient than using strcmp(), and is more useful to the gcv_guest case than having to fabricate a suitable string to pass. The gcv_host cases have both options easily to hand, and experimentally, the resulting code is more efficient. While modifying

[Xen-devel] domU's pseudo physical address mapping

Hi All, This is my first mail to this mail list, and nice to meet all of you! Right now I'm porting XEN 4.8 to an ARMv8 board and I had met some problems with domU's pseudo physical address mapping. Here is my situation: I have a display control hardware that can move data from framebuffer to a

Re: [Xen-devel] [PATCH] libxl: fix libxl_set_memory_target [and 1 more messages]

Ian Jackson writes ("Re: Stale Xenstore entries after start of domU with stubdom"): > What is the uuid ? It's probably the stubdom or the main domain. > (Try `xl list -l'.) Never mind, I have just realised that Wei's patch (below) is a reply to this. Wei Liu writes ("[PATCH] libxl: fix

Re: [Xen-devel] [PATCH] x86/vvmx: Drop sreg_to_index[]

>>> On 03.01.17 at 12:58, wrote: > Since c/s 0888d36b "x86/emul: Correct the decoding of SReg3 operands", > x86_seg_* have followed hardware encodings, meaning that this translation > table is now an identiy transform. > > No functional change. > > Signed-off-by:

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

>-Original Message- >From: Jan Beulich [mailto:jbeul...@suse.com] >Sent: Tuesday, January 03, 2017 3:35 PM >To: Xuquan (Quan Xu) >Cc: Andrew Cooper; George Dunlap; yang.zhang...@gmail.com; Chao Gao; >Jun Nakajima; Kevin Tian; Lan Tianyu; xen-devel@lists.xen.org >Subject: RE: [PATCH v4]

[Xen-devel] [xen-unstable-smoke test] 104007: tolerable all pass - PUSHED

flight 104007 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104007/ 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

Re: [Xen-devel] [PATCH v2 2/2] p2m: split mem_access into separate files

On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel wrote: > This patch relocates mem_access components that are currently mixed with p2m > code into separate files. This better aligns the code with similar subsystems, > such as mem_sharing and mem_paging, which are

[Xen-devel] [RFC] kbdif: add multi-touch support

From: Oleksandr Andrushchenko Hi, all! I am working on adding multi-touch support to the existing kbdif protocol and would like to request for comments on the below patch. The aim is to provide multi-touch support to unprivileged domains which may employ

[Xen-devel] [RFC] kbdif: add multi-touch support

From: Oleksandr Andrushchenko Signed-off-by: Oleksandr Andrushchenko --- xen/include/public/io/kbdif.h | 64 +++ 1 file changed, 64 insertions(+) diff --git

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

>>> On 03.01.17 at 16:22, wrote: > On 03/01/17 13:10, Jan Beulich wrote: >> --- a/xen/arch/x86/hvm/emulate.c >> +++ b/xen/arch/x86/hvm/emulate.c >> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg( >> return hvmemul_write(seg, offset, p_new, bytes, ctxt); >> } >>

Re: [Xen-devel] [PATCH v2 06/10] x86/SVM: Add AVIC vmexit handlers

> + > +static int avic_ldr_write(struct vcpu *v, u8 g_phy_id, u32 ldr, bool valid) > +{ > +struct avic_log_apic_id_ent *entry, new_entry; > +u32 *bp = avic_get_bk_page_entry(v, APIC_DFR); dfr would be a better name (and you use it in avic_handle_dfr_update()). Also, 'logical' instead of

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

On Fri, Dec 23, 2016 at 12:13:47PM -0500, Boris Ostrovsky wrote: > On 12/23/2016 11:02 AM, Konrad Rzeszutek Wilk wrote: > > On Fri, Dec 23, 2016 at 10:35:10AM -0500, Boris Ostrovsky wrote: > >> On 12/23/2016 10:31 AM, Konrad Rzeszutek Wilk wrote: > But this still assumes that dom0 handles

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

> > +static void avic_dump(unsigned char ch) > +{ > +struct domain *d; > +struct vcpu *v; > + > +printk("*** SVM AVIC Statistics **\n"); > + > +rcu_read_lock(_read_lock); > + > +for_each_domain ( d ) > +{ > +if ( !is_hvm_domain(d) ) ||

Re: [Xen-devel] [RFC] kbdif: add multi-touch support

>>> On 03.01.17 at 16:39, wrote: > --- a/xen/include/public/io/kbdif.h > +++ b/xen/include/public/io/kbdif.h > @@ -45,6 +45,19 @@ > */ > #define XENKBD_TYPE_POS 4 > > +/* > + * Multi-touch event > + * Capable backend sets feature-multi-touch in xenstore. > + *

[Xen-devel] [distros-debian-snapshot test] 68308: tolerable FAIL

flight 68308 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68308/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 68277

Re: [Xen-devel] [PATCH v2 1/2] arm/mem_access: adjust check_and_get_page to not rely on current

On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel wrote: > The only caller of this function is get_page_from_gva which already takes > a vcpu pointer as input. Pass this along to make the function in-line with > its intended use-case. > > Signed-off-by: Tamas K Lengyel

Re: [Xen-devel] [PATCH v2 07/10] x86/SVM: Add vcpu scheduling support for AVIC

On 12/31/2016 12:45 AM, Suravee Suthikulpanit wrote: > Add hooks to manage AVIC data structure during vcpu scheduling. > > Signed-off-by: Suravee Suthikulpanit > Cc: Konrad Rzeszutek Wilk > Cc: Jan Beulich > Cc: Boris

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

>>> On 03.01.17 at 13:06, wrote: > Comparing 3 integers is more efficient than using strcmp(), and is more useful > to the gcv_guest case than having to fabricate a suitable string to pass. The > gcv_host cases have both options easily to hand, and experimentally, the

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

On 03/01/17 13:01, 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). > > Note that the result is not fully consistent until after at least one > more patch is in place, primarily to limit patch

Re: [Xen-devel] [PATCH v2 05/10] x86/HVM/SVM: Add AVIC initialization code

> + > +#define AVIC_DOORBELL 0xc001011b MSR_AVIC_DOORBELL (and it should probably go to include/asm-x86/msr-index.h) > + > +#define AVIC_HPA_SHIFT 12 Is there a reason not to use regular PAGE_SHIFT? > +#define AVIC_HPA_MASK (((1ULL << 40) - 1) << AVIC_HPA_SHIFT) >

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

>>> On 03.01.17 at 15:12, wrote: On 03.01.17 at 14:30, wrote: >> On 03/01/17 13:01, Jan Beulich wrote: >>> @@ -2716,36 +2716,36 @@ x86_emulate( >>> struct segment_register cs, sreg; >>> >>> case 0x00 ... 0x05: add: /* add */ >>>

[Xen-devel] [xen-unstable-smoke test] 104011: tolerable all pass - PUSHED

flight 104011 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104011/ 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

Re: [Xen-devel] [PATCH v2 10/10] x86/SVM: Add AMD AVIC key handler

On 03/01/17 16:01, Boris Ostrovsky wrote: >> >> +static void avic_dump(unsigned char ch) >> +{ >> +struct domain *d; >> +struct vcpu *v; >> + >> +printk("*** SVM AVIC Statistics **\n"); >> + >> +rcu_read_lock(_read_lock); >> + >> +for_each_domain ( d ) >>

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

From: Nicolas Dichtel Date: Tue, 3 Jan 2017 15:35:44 +0100 > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all

[Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

Most invocations of the instruction emulator are for VM exits where the set of legitimate instructions (i.e. ones capable of causing the respective exit) is rather small. Restrict the permitted sets via a new callback, at once eliminating the abuse of handle_mmio() for non-MMIO operations.

[Xen-devel] [ovmf baseline-only test] 68309: all pass

This run is configured for baseline tests only. flight 68309 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68309/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7c6075e2546dd818b7b87090a983429b1942796a baseline

[Xen-devel] [PATCH v6 03/12] pvh/acpi: Install handlers for ACPI-related PVH IO accesses

PVH guests will have ACPI accesses emulated by the hypervisor as opposed to QEMU (as is the case for HVM guests). This patch installs handler for accesses to PM1A, GPE0 (which is added to struct hvm_hw_acpi) and VCPU map. Logic for the handler will be provided by a later patch. Whether or not the

[Xen-devel] [PATCH v6 09/12] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

Provide libxc interface for accessing ACPI via XEN_DOMCTL_acpi_access. When a VCPU is hot-(un)plugged to/from a PVH guest update VCPU map by writing to ACPI's XEN_ACPI_CPU_MAP register and then set GPE0 status bit in GPE0.status. Signed-off-by: Boris Ostrovsky ---

[Xen-devel] [PATCH v6 10/12] pvh: Set online VCPU map to avail_vcpus

ACPI builder marks VCPUS set in vcpu_online map as enabled in MADT. With ACPI-based CPU hotplug we only want VCPUs that are started by the guest to be marked as such. Remaining VCPUs will be set to "enable" by AML code during hotplug. Signed-off-by: Boris Ostrovsky

[Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

Signed-off-by: Boris Ostrovsky Reviewed-by: Konrad Rzeszutek Wilk --- CC: George Dunlap CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Tim Deegan

[Xen-devel] [PATCH v6 11/12] pvh/acpi: Save ACPI registers for PVH guests

Signed-off-by: Boris Ostrovsky --- Can't generate SCI over event channel during is an event is enabled and pending: * v->virq_to_evtchn is not initialized yet (it's done by guest) * The SCI is sent immediately after event is made pending so it's not possible to miss

[Xen-devel] [PATCH v6 04/12] pvh/acpi: Handle ACPI accesses for PVH guests

Subsequent domctl access VCPU map will use the same code. We create acpi_cpumap_access_common() routines in anticipation of these changes. Signed-off-by: Boris Ostrovsky --- Changes in v6: * ACPI registers are only accessed by guest code (not by domctl), thus

[Xen-devel] [PATCH v6 05/12] x86/domctl: Handle ACPI access from domctl

Signed-off-by: Boris Ostrovsky --- Changes in v6: * Adjustments to to patch 4 changes. * Added a spinlock for VCPU map access * Return an error on guest trying to write VCPU map xen/arch/x86/hvm/acpi.c | 57 +++-

[Xen-devel] [PATCH v6 00/12] PVH VCPU hotplug support

This series adds support for ACPI-based VCPU hotplug for unprivileged PVH guests. Main changes in v6: * Generate SCI on VCPU map update by domctl * Simplify public domctl structure * Make ACPI registers accessible only by guest (and not by domctl) * Update VCPU map under lock * Fix pointer update

[Xen-devel] [PATCH] uapi: use wildcards to list files

Regularly, when a new header is created in include/uapi/, the developer forgets to add it in the corresponding Kbuild file. This error is usually detected after the release is out. In fact, all headers under include/uapi/ should be exported, so let's use wildcards. After this patch, the

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

On 03/01/17 13:10, Jan Beulich wrote: > Most invocations of the instruction emulator are for VM exits where the > set of legitimate instructions (i.e. ones capable of causing the > respective exit) is rather small. Restrict the permitted sets via a new > callback, at once eliminating the abuse of

Re: [Xen-devel] [PATCH] x86/VMX: use unambiguous register names

On 03/01/17 13:01, Jan Beulich wrote: > @@ -1321,10 +1321,10 @@ static void virtual_vmexit(struct cpu_us > if ( lm_l1 != lm_l2 ) > paging_update_paging_modes(v); > > -regs->eip = get_vvmcs(v, HOST_RIP); > -regs->esp = get_vvmcs(v, HOST_RSP); > +regs->rip = get_vvmcs(v,

[Xen-devel] [xen-unstable-smoke test] 104010: tolerable all pass - PUSHED

flight 104010 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/104010/ 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

Re: [Xen-devel] [PATCH] xen: events: Replace BUG() with BUG_ON()

On 24/12/16 09:52, Shyam Saini wrote: > Replace BUG() with BUG_ON() using coccinelle > > Signed-off-by: Shyam Saini Committed to xen/tip.git for-linus-4.10 Thanks, Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

>>> On 03.01.17 at 15:38, wrote: > Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict > -Werror checking"): >> Alistair Francis 12/22/16 8:14 PM >>> >> >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

On 03/01/17 12:40, Jan Beulich wrote: On 03.01.17 at 13:06, wrote: >> Comparing 3 integers is more efficient than using strcmp(), and is more >> useful >> to the gcv_guest case than having to fabricate a suitable string to pass. >> The >> gcv_host cases have

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

>>> On 03.01.17 at 14:30, wrote: > On 03/01/17 13:01, Jan Beulich wrote: >> --- a/xen/arch/x86/x86_emulate.c >> +++ b/xen/arch/x86/x86_emulate.c >> @@ -21,6 +21,8 @@ >> #undef cpuid >> #undef wbinvd >> >> +#define r(name) r ## name >> + > > Hmm. I am no

Re: [Xen-devel] [PATCH] x86emul: use unambiguous register names

On 03/01/17 14:12, Jan Beulich wrote: > >>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h >>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h >>> @@ -583,41 +583,9 @@ x86_emulate( >>> const struct x86_emulate_ops *ops); >>> >>> #ifndef NDEBUG >>> -/* >>> - * In debug builds, wrap x86_emulate()

Re: [Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

On 03/01/17 13:02, Jan Beulich wrote: > This involves protmode_load_seg() accepting x86_seg_none as input, with > the meaning to > - suppress any exceptions other than #PF, > - not commit any state. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

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

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

[Xen-devel] [PATCH] x86/VMX: use unambiguous register names

This is in preparation of eliminating the mis-naming of 64-bit fields with 32-bit register names (eflags instead of rflags etc). Use the guaranteed 32-bit underscore prefixed names for now where appropriate. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmx/vmcs.c +++

[Xen-devel] [PATCH] x86emul: use unambiguous register names

This is in preparation of eliminating the mis-naming of 64-bit fields with 32-bit register names (eflags instead of rflags etc). Note that the result is not fully consistent until after at least one more patch is in place, primarily to limit patch size (by trying to not touch the same line

[Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

This involves protmode_load_seg() accepting x86_seg_none as input, with the meaning to - suppress any exceptions other than #PF, - not commit any state. Signed-off-by: Jan Beulich --- v3: Re-base. v2: Extend commit message and add a respective code comment. Add ASSERT()s

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking"): > Alistair Francis 12/22/16 8:14 PM >>> > >Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues > >as I still see warnings/errors when building:

Re: [Xen-devel] [PATCH v3] x86emul: support LAR/LSL/VERR/VERW

>>> On 03.01.17 at 15:56, wrote: > On 03/01/17 13:02, Jan Beulich wrote: >> This involves protmode_load_seg() accepting x86_seg_none as input, with >> the meaning to >> - suppress any exceptions other than #PF, >> - not commit any state. >> >> Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

>>> On 03.01.17 at 13:41, wrote: > On 03/01/17 12:40, Jan Beulich wrote: >> For the patch itself >> Reviewed-by: Jan Beulich > > Does this still stand if I split the patch into two, for easier backport? Yes. Jan

[Xen-devel] [PATCH v6 07/12] pvh: Send an SCI on VCPU hotplug event

Send and SCI when VCPU map is updated by domctl or when guest sets GPE0 enable bit and status bit is already set. Also update send_guest_global_virq() to handle cases when VCPU0 is offlined. Signed-off-by: Boris Ostrovsky --- Changes in v6: * Change conditions

[Xen-devel] [PATCH v6 02/12] x86/save: public/arch-x86/hvm/save.h is available to hypervisor and tools only

Noone else needs to include it since it is only useful to code that can made domctl calls. And public domctl.h can only be included by the toolstack or the hypervisor. Signed-off-by: Boris Ostrovsky --- New in v6 (not required by the series). Q: Should

[Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

This domctl will allow toolstack to read and write some ACPI registers. It will be available to both x86 and ARM but will be implemented first only for x86 Signed-off-by: Boris Ostrovsky --- CC: Daniel De Graaf --- Changes in v6: * Fold

[Xen-devel] [PATCH v6 06/12] events/x86: Define SCI virtual interrupt

PVH guests do not have IOAPIC which typically generates an SCI. For those guests SCI will be provided as a virtual interrupt. Copy VIRQ_MCA definition from of xen-mca.h to xen.h to keep all x86-specific VIRQ_ARCH_* in one place. (However, because we don't want to require inclusion of xen.h in

[Xen-devel] [PATCH v6 08/12] libxl: Update xenstore on VCPU hotplug for all guest types

Currently HVM guests that use upstream qemu do not update xenstore's availability entry for VCPUs. While it is not strictly necessary for hotplug to work, xenstore ends up not reflecting actual status of VCPUs. We should fix this. Signed-off-by: Boris Ostrovsky ---

Re: [Xen-devel] [PATCH V2] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

On Mon, 2 Jan 2017, Juergen Gross wrote: > On 28/12/16 01:47, Jiandi An wrote: > > Ensure all reserved fields of xatp are zero before making > > hypervisor call to XEN in xen_map_device_mmio(). > > xenmem_add_to_physmap_one() in XEN fails the mapping request if > > extra.res reserved field in xatp

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

On Tue, 3 Jan 2017, Boris Ostrovsky wrote: > Signed-off-by: Boris Ostrovsky > Reviewed-by: Konrad Rzeszutek Wilk > --- > CC: George Dunlap > CC: Konrad Rzeszutek Wilk > CC: Stefano

[Xen-devel] [ovmf baseline-only test] 68310: all pass

This run is configured for baseline tests only. flight 68310 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68310/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 32ea56f0a65b80324e3e651432bdf496a6fc55b7 baseline

Re: [Xen-devel] [PATCH RFC 59/59] tools/xenlight: Create interface for xenlight info

On Thu, Dec 29, 2016 at 01:45:54PM +, George Dunlap wrote: > Hey Ronald! Looks like you're getting going pretty well here. > > At a high level: I think I began by saying that this would probably all > be a single patch. But I think it would probably be easier to review > the different

Re: [Xen-devel] [PATCH v6 02/12] x86/save: public/arch-x86/hvm/save.h is available to hypervisor and tools only

>>> On 03.01.17 at 15:04, wrote: > Noone else needs to include it since it is only useful to code > that can made domctl calls. And public domctl.h can only be included > by the toolstack or the hypervisor. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

On 03/01/17 16:19, Jan Beulich wrote: On 03.01.17 at 16:22, wrote: >> On 03/01/17 13:10, Jan Beulich wrote: >>> --- a/xen/arch/x86/hvm/emulate.c >>> +++ b/xen/arch/x86/hvm/emulate.c >>> @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg( >>> return

Re: [Xen-devel] [PATCH v3 4/5] Xen: Select correct dom0 console

On Thu, Dec 15, 2016 at 12:27:17PM +, Andre Przywara wrote: > From: Ian Campbell > > If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to > the usual ttyAMA0 otherwise. > > Signed-off-by: Ian Campbell > Signed-off-by:

Re: [Xen-devel] [PATCH v3 0/5] boot-wrapper: arm64: Xen support

On Thu, Dec 15, 2016 at 12:27:13PM +, Andre Przywara wrote: > These patches allow to include a Xen hypervisor binary into a boot-wrapper > ELF file, so that a Foundation Platform or a Fast Model can boot a Xen > system (including a Dom0 kernel). Thanks! I've applied the series and pushed it

[Xen-devel] [PATCH] x86/svm: Replace opencoded 1GB superpage check

No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Boris Ostrovsky CC: Suravee Suthikulpanit --- xen/arch/x86/hvm/svm/svm.c | 2 +- 1 file changed, 1 insertion(+),

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

>>> On 03.01.17 at 15:04, wrote: > --- a/docs/misc/hvmlite.markdown > +++ b/docs/misc/hvmlite.markdown > @@ -75,3 +75,14 @@ info structure that's passed at boot time (field > rsdp_paddr). > > Description of paravirtualized devices will come from XenStore, just as

Re: [Xen-devel] How to find device name in order to fill STAO ACPI table

On 3 January 2017 at 17:50, Al Stone wrote: > On 12/23/2016 05:51 AM, Roger Pau Monné wrote: >> Hello, >> >> I've been looking into the STAO specification[0], because I think it would >> also >> be useful for x86 PVHv2 Dom0, but I'm not really sure how is Xen supposed to >>

Re: [Xen-devel] [PATCH v6 01/12] domctl: Add XEN_DOMCTL_acpi_access

On 01/03/2017 09:04 AM, Boris Ostrovsky wrote: This domctl will allow toolstack to read and write some ACPI registers. It will be available to both x86 and ARM but will be implemented first only for x86 Signed-off-by: Boris Ostrovsky Acked-by: Daniel De Graaf

[Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

Happy New Year! This is a very minor rebase from v5. It only moves a few headers around. I think this series should be ready to be queued up for 4.11. Thanks, Laura Laura Abbott (11): lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL mm/cma: Cleanup highmem check arm64: Move some macros under

Re: [Xen-devel] Future support of 5-level paging in Xen

On 08/12/16 23:40, Boris Ostrovsky wrote: On 12/08/2016 05:21 PM, Andrew Cooper wrote: On 08/12/2016 19:18, Stefano Stabellini wrote: Of course even the largest virtual machine today (2TB on Amazon AFAIK) is not close to reaching the current memory limit, but it's just a matter of

Re: [Xen-devel] [RFC] Xen PV Drivers Lifecycle

On Wed, 28 Dec 2016, George Dunlap wrote: > On Tue, Dec 20, 2016 at 11:09 PM, Stefano Stabellini > wrote: > > On Tue, 20 Dec 2016, Jan Beulich wrote: > >> >>> On 20.12.16 at 01:47, wrote: > >> > ## Design Phase > >> > > >> > The first step toward

Re: [Xen-devel] [PATCH] xsm: allow relevant permission during migrate and gpu-passthrough.

On 12/19/2016 11:03 PM, 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 spurious page faults. Prevents these errors: d73: Non-privileged

Re: [Xen-devel] Xen: Support for mapping OperationRegion in ACPI ASL

On Thu, 22 Dec 2016, Jan Beulich wrote: > >>> On 20.12.16 at 23:50, wrote: > > On Tue, 20 Dec 2016, Jan Beulich wrote: > >> >>> On 20.12.16 at 00:01, wrote: > >> > This is actually not an ARM specific question, so changing the subject > >> > and

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

> We can provide a crafted MADT that reflects the number of vCPUs available to > Dom0 at boot time, let Dom0 find the Processor objects in the ACPI namespace > and perform pCPU hotplug as it's been done until now. Then for Dom0 vCPU > hotplug we would need to use the hypercall interface as it's

Re: [Xen-devel] Xen: ARM: Support for mapping ECAM PCIe Config Space Specified In Static ACPI Table

On Wed, 28 Dec 2016, Julien Grall wrote: > (CC Andrew and Jan) > > Hi Stefano, > > On 20/12/16 22:33, Stefano Stabellini wrote: > > On Tue, 20 Dec 2016, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 20/12/2016 00:54, Stefano Stabellini wrote: > > > > On Mon, 19 Dec 2016, Julien Grall

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

On 01/03/2017 11:58 AM, Jan Beulich wrote: On 03.01.17 at 15:04, wrote: >> --- a/docs/misc/hvmlite.markdown >> +++ b/docs/misc/hvmlite.markdown >> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field >> rsdp_paddr). >> >> Description of

[Xen-devel] [xen-unstable test] 104008: regressions - FAIL

flight 104008 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104008/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 6 xen-bootfail REGR. vs. 104004

Re: [Xen-devel] Future support of 5-level paging in Xen

On 01/03/2017 12:32 PM, anshul makkar wrote: > > > On 08/12/16 23:40, Boris Ostrovsky wrote: >> >> >> On 12/08/2016 05:21 PM, Andrew Cooper wrote: >>> On 08/12/2016 19:18, Stefano Stabellini wrote: >> >>> Of course even the largest virtual machine today (2TB on Amazon AFAIK) is not close

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

On Thu, 29 Dec 2016, Julien Grall wrote: > Hi all, > > The document below is an early version of a design > proposal for PCI Passthrough in Xen. It aims to > describe from an high level perspective the interaction > with the different subsystems and how guest will be able > to discover and access

Re: [Xen-devel] [PATCH v5 09/14] jump_label: port __jump_table to linker tables

On Thu, Dec 22, 2016 at 04:08:22PM +0200, Andy Shevchenko wrote: > 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

Re: [Xen-devel] [PATCH v2 1/4] xen/arm: fix GIC_INVALID_LR

On Wed, 28 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 22/12/16 02:15, Stefano Stabellini wrote: > > GIC_INVALID_LR should be 0xff, but actually, defined as ~(uint8_t)0, is > > 0x. Fix the problem by placing the ~ operator before the cast. > > > > Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [PATCH v2 4/4] The locking order is: first rank lock, then vgic lock. The order is respected everywhere, except for gic_update_one_lr.

On Wed, 28 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 22/12/16 02:15, Stefano Stabellini wrote: > > gic_update_one_lr is called with the vgic lock held, but it calls > > vgic_get_target_vcpu, which tries to obtain the rank lock. This can > > cause deadlocks. > > > > We already have a

Re: [Xen-devel] [PATCH] x86/svm: Replace opencoded 1GB superpage check

On 01/03/2017 12:53 PM, Andrew Cooper wrote: > No functional change. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Boris Ostrovsky > CC: Suravee Suthikulpanit Reviewed-by:

Re: [Xen-devel] [PATCH v2 3/4] arm, vgic_migrate_irq: take the right vgic lock

On Wed, 28 Dec 2016, Julien Grall wrote: > Hi Stefano, > > On 22/12/16 02:15, Stefano Stabellini wrote: > > Always take the vgic lock of the old vcpu. When more than one irq > > migration is requested before the first one completes, take the vgic > > lock of the oldest vcpu. > > > > Write the

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

On Tuesday, January 3, 2017 3:35:44 PM CET Nicolas Dichtel wrote: > Regularly, when a new header is created in include/uapi/, the developer > forgets to add it in the corresponding Kbuild file. This error is usually > detected after the release is out. > > In fact, all headers under include/uapi/

  1   2   >