similar to: FreeBSD PVH guest support

Good afternoon, The subject practically is saying what I''m trying to ask but... does anyone tried FreeBSD 8.2 or similar under Cytrix Xenserver or XenCloud?. I have been doing some benchmarks and seems to perform pretty nice... and seems to be stable too; the only thing would be nice to be available for FreeBSD at Xenserver/Xencloud would be the Xenserver/Xencloud''s

Hi John, configure still exits, when checking for uint64_t. I've attached a patch, that properly will fix it. Either uint64_t or u_int64_t will succeed: Index: configure.ac =================================================================== RCS file: /var/cvs/llvm/llvm/autoconf/configure.ac,v retrieving revision 1.106 diff -u -r1.106 configure.ac --- configure.ac 2 Sep 2004 18:44:44 -0000

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

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:

Hey all, We've been on 4.9 for some time now, and while it's still supported, I think it's time to start thinking about upgrading, and I'd like input from the community about which version to move up to. 4.19 has been out for almost 5 months now. It will include PVH domU support, and PVH dom0 support in what _is believed_ to be the final form; so when the Virt SIG moves to a

Hi R-helpers, I'm trying to use this code > pvh_dnv<-pvh[sapply(pvh=="dnv"),] to make a new dataframe containing the rows from pvh that contain the value of "dnv" in ANY column. But, it's not working. I get this error Error in match.fun(FUN) : element 1 is empty; the part of the args list of 'is.function' being evaluated was: (FUN) which, to

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

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.

On 3/7/19 10:30 AM, Akemi Yagi wrote: > On Thu, Mar 7, 2019 at 9:42 AM George Dunlap <dunlapg at umich.edu> wrote: >> >> Hey all, >> >> We've been on 4.9 for some time now, and while it's still supported, I >> think it's time to start thinking about upgrading, and I'd like input >> from the community about which version to move up to.

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

On Mon, Dec 02, 2013 at 05:11:49PM +0100, Roger Pau Monn? wrote: > Hello, > > I''ve yet updated the PVH work one more time, regarding some comments > from emaste in order to try to make this work easier to merge with the > UEFI changes. In this regard, the parse_memmap hook now fetches and > parses the memmap, so UEFI can define it''s own hook and do the fetching

Reid, When configuring LLVM I get this error: ----------------- checking for uint64_t... no configure: error: Type uint64_t required but not found ----------------- However, this type exists as u_int64_t in /usr/include/types.h. The easy way for me is to edit types.h, but I think the right thing is to somehow to test for it on Interix platform. Any thoughts? /Henrik --- Got Freedom?

ssh won't compile on this platform log: gcc -g -O2 -Wall -I/usr/local/ssl/include -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh/ssh-askpass\" -DHAVE_CONFIG_H -c atomicio.c -o atomicio.o In file included from config.h:294, from bsd-misc.h:39, from includes.h:91,

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 >>

This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 Our timeline had us start the code freeze last Friday. However, we have not released an RC0 because we have been waiting for PVH dom0 support. Adding bug fixes during RCs makes sense, but RC0 should contain all of the functionality we expect to be in the final release. PVH dom0 support

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

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

Henrik Bach wrote: } Hi John, } } configure still exits, when checking for uint64_t. I've attached a patch, } that properly will fix it. Either uint64_t or u_int64_t will succeed: } } Index: configure.ac } =================================================================== } RCS file: /var/cvs/llvm/llvm/autoconf/configure.ac,v } retrieving revision 1.106 } diff -u -r1.106 configure.ac } ---

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

Reid, >Well, if it doesn't break anything else, I'd fix the header file. The >standard type name is supposed to uint64_t not u_int64_t. I would just >change the header file to define both of them, something like: > >typedef u_int64_t uint64_t; > >You could do that in /usr/include/types.h, I've tried it and it doesn't break anything, but ... >or we could