similar to: Xen 4.4 development update: Is PVH a blocker?

This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 We''re nearly to the completion of the code freeze, scheduled for tomorrow. After the code freeze, only bug fixes and features marked as "blockers" will be considered. At the moment, the only feature considered a blocker is experimental PVH dom0 support. In early RCs,

The aim of this patch is to define a stable way in which PVH is going to do AP bringup. Since we are running inside of a HVM container, PVH should only need to set flags, cr3 and user_regs in order to bring up a vCPU, the rest can be set once the vCPU is started using the bare metal methods. Additionally, the guest can also set cr0 and cr4, and those values will be appended to the default values

It was decided during xen patch review that xen map the iomem transparently, so remove xen_set_clr_mmio_pvh_pte() and the sub hypercall PHYSDEVOP_map_iomem. --- arch/x86/xen/mmu.c | 14 -------------- arch/x86/xen/setup.c | 16 ++++------------ include/xen/interface/physdev.h | 10 ---------- 3 files changed, 4 insertions(+), 36 deletions(-) diff --git

Hello, I''ve had a look at PVH support, and I have a few questions: - events are still dispatched the PV way through the callback, right? - I guess FPU errors don''t trigger an INT13, so I don''t need to handle that? - How about the console and store MFNs from the boot info? Are they still MFNs, or actually PFNs? - How about PV network in non-copy mode? It used to be

On Thu, 17 Jan 2013 22:22:47 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Jan had some comments about that patch: > > https://patchwork.kernel.org/patch/1745041/ > > Please fix it up so I can put it in the Linux tree. Please see below. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Thanks, Mukesh diff --git a/arch/x86/xen/xen-head.S

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com> Cc: Mukesh Rathor <mukesh.rathor at

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com> Cc: Mukesh Rathor <mukesh.rathor at

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com> Cc: Mukesh Rathor <mukesh.rathor at

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com> Cc: Mukesh Rathor <mukesh.rathor at

Hi, V6: The only change from V5 is in patch #6: - changed comment to reflect autoxlate - removed a redundant ASSERT - reworked logic a bit so that get_page_from_gfn() is called with NULL for p2m type as before. arm has ASSERT wanting it to be NULL. Tim: patch 4 needs your approval. Daniel: patch 5 needs your approval. These patches implement PVH dom0. Patches 1 and 2

Hi, I'm instresting with the PVH mode, is there any wiki available to boot up a PVH guest? I used the following source code to compile the xen and dom0. I have tried adding pvh=1 in xl.cfg file as pv mode, but guest still uses qemu device model. This patch series can also be pulled from this git tree: git://xenbits.xen.org/people/gdunlap/xen.git out/pvh-v15 The kernel code for PVH guests

There are basically three issues we''re waiting to sort out (see below for more info): * XSA-55 * cpu hotplug in qemu-upsream * The MMIO hole issue Unfortuantely, there is considerable uncertainty about how long it will take for each of those to complete. We''re hoping to be able to release maybe on the 19th, This information will be mirrored on the Xen 4.3 Roadmap wiki page:

On 1/6/19 11:21 AM, Colin Watson wrote: > On Sat, Jan 05, 2019 at 10:51:13PM +0100, Hans van Kranenburg wrote: >> On 1/5/19 8:04 PM, Colin Watson wrote: >>> I think I'm OK with cherry-picking the relevant patch stack. Presumably >>> this would need to be in new grub-xen-pvh-bin / grub-xen-pvh binary >>> packages, as is usual for separate platform builds?

Hello @ all, i wonder if there is any support for Xen PVH (https://wiki.xen.org/wiki/Xen_Project_Software_Overview) within libvirt. If i parse a xen native domU config file with 'virsh domxml-from-native' in which i set type='pvh' it changes it in the libvirt xml output to normal pv. Also the docs of libvirt do not state something like pvh. I am currently running Xen 4.10.0 with

Hi Colin, Thanks for the quick reply. On 1/5/19 8:04 PM, Colin Watson wrote: > On Thu, Jan 03, 2019 at 01:02:47AM +0100, Hans van Kranenburg wrote: >> In december, Xen PVH support has been committed in grub master: >> https://www.mail-archive.com/grub-devel at gnu.org/msg28125.html >> >> The last pieces needed in the Linux kernel to boot PVH with grub2 landed >>

Hi Debian Grub maintainer, In december, Xen PVH support has been committed in grub master: https://www.mail-archive.com/grub-devel at gnu.org/msg28125.html The last pieces needed in the Linux kernel to boot PVH with grub2 landed in Linux 4.20. I asked our kernel team to carry those patches on top of the Linux 4.19 kernel that is going to ship in Buster, and that wish was granted:

On Mon, Jan 07, 2019 at 08:44:50AM +0000, Colin Watson wrote: > On Mon, Jan 07, 2019 at 01:58:19AM +0100, Hans van Kranenburg wrote: > > Ok great. Since I'm not using (and probably not going to use) the > > multi-stage multiboot things, this is harder for me to help with. > > With any luck I should be able to work that bit out myself, since I > think stable's Xen

From: Mukesh Rathor <mukesh.rathor@oracle.com> Use .ascii and .asciz to define xen feature string. Note, the PVH string must be in a single line (not multiple lines with \) to keep the assembler from putting null char after each string before \. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> ---

George, since you asked on Friday, I though about the situation some more over the weekend. On PV, the requirement to trap all INs and OUTs is a result from us needing the enforce two levels of restrictions - Xen''s and the guest kernel''s. I.e. we can''t make use of the hardware''s access control mechanisms, as we can''t put two I/O bit maps in place, and