[Xen-devel] [PATCH v5 7/7] KVM: x86: Allow Qemu/KVM to use PVH entry point

For certain applications it is desirable to rapidly boot a KVM virtual machine. In cases where legacy hardware and software support within the guest is not needed, Qemu should be able to boot directly into the uncompressed Linux kernel binary without the need to run firmware. There already exists

Re: [Xen-devel] [PATCH v5 1/7] xen/pvh: Split CONFIG_XEN_PVH into CONFIG_PVH and CONFIG_XEN_PVH

Hi, On 03/20/2018 12:18 PM, Maran Wilson wrote: > In order to pave the way for hypervisors other then Xen to use the PVH than > entry point for VMs, we need to factor the PVH entry code into Xen specific > and hypervisor agnostic components. The

Re: [Xen-devel] [PATCH 12/20] xen/domctl: Merge max_vcpus into createdomain

On 03/19/2018 03:13 PM, Andrew Cooper wrote: XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a toolstack from unpausing a domain with no vcpus. Originally, d->vcpus[] was an embedded array in struct domain, but c/s fb442e217 "x86_64: allow more vCPU-s per guest" in

Re: [Xen-devel] [PATCH 10/20] xen/domctl: Merge set_max_evtchn into createdomain

On 03/19/2018 03:13 PM, Andrew Cooper wrote: set_max_evtchn is somewhat weird. It was introduced with the event_fifo work, but has never been used. Still, it is a bounding on resources consumed by the event channel infrastructure, and should be part of createdomain, rather than editable after

Re: [Xen-devel] Spectre Mitigations in Xen 4.6

On Tue, Mar 20, 2018 at 11:20 AM, Jan Beulich wrote: On 20.03.18 at 13:58, wrote: >> With that in place, I'm seeing Dom0 receive a general protection fault on >> boot >> >> [ 25.460035] general protection fault: [#1] SMP >> [ 25.460292] EIP:

Re: [Xen-devel] [PATCH 12/20] xen/domctl: Merge max_vcpus into createdomain

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a > toolstack from unpausing a domain with no vcpus. > > Originally, d->vcpus[] was an embedded array in struct domain, but c/s >

Re: [Xen-devel] [PATCH 11/20] xen/domctl: Merge set_gnttab_limits into createdomain

> On 20. Mar 2018, at 10:11, Andrew Cooper wrote: > > That said, while ssidref might plausibly need a full 32 bits of range > (and even then, I'm not entirely sure, but it is an opaque handle at the > end of the day), none of the max_* fields do. vcpus is currently

Re: [Xen-devel] [PATCH 10/20] xen/domctl: Merge set_max_evtchn into createdomain

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > set_max_evtchn is somewhat weird. It was introduced with the event_fifo work, > but has never been used. Still, it is a bounding on resources consumed by the > event channel infrastructure, and should be part of

Re: [Xen-devel] [PATCH 06/20] tools/ocaml: Drop domain_create_flag_table[]

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > This is a logarithm in disguise. Update the logic to match how > x86_arch_emulation_flags works in c/s 9d683b5e37 and b38d96f596. Acked-by: Christian Lindig

Re: [Xen-devel] [PATCH 09/20] tools: Rework xc_domain_create() to take a full xen_domctl_createdomain

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > In future patches, the structure will be extended with further information, > and this is far cleaner than adding extra parameters. > > The python stubs are the only user which passes NULL for the existing config

Re: [Xen-devel] [PATCH 08/20] tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()

> On 19. Mar 2018, at 19:13, Andrew Cooper wrote: > > The underlying C function is about to make the same change, and the structure > is going to gain extra fields. > > Signed-off-by: Andrew Cooper Acked-by: Christian Lindig

[Xen-devel] [xen-unstable-smoke test] 121001: regressions - FAIL

flight 121001 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/121001/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm 7 xen-boot fail REGR. vs. 120949 Tests which

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

On 20/03/18 19:48, osstest service owner wrote: > flight 121001 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/121001/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-arm64-arm64-xl-xsm

<    1   2   3