search for: hypervisores

Hi, Please find below the proposal for the generic use of cpuid space allotted for hypervisors. Apart from this cpuid space another thing worth noting would be that, Intel & AMD reserve the MSRs from 0x40000000 - 0x400000FF for software use. Though the proposal doesn't talk about MSR's right now, we should be aware of these reservations as we may want to extend the way we use CPUID to

Hi, Please find below the proposal for the generic use of cpuid space allotted for hypervisors. Apart from this cpuid space another thing worth noting would be that, Intel & AMD reserve the MSRs from 0x40000000 - 0x400000FF for software use. Though the proposal doesn't talk about MSR's right now, we should be aware of these reservations as we may want to extend the way we use CPUID to

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9+deb8u1 Severity: critical Justification: breaks the whole system Dear Maintainer, -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8,

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

We try to handle the hypervisor compatibility mode by detecting hypervisor through a specific order. This is not robust, since hypervisors may implement each others features. This patch tries to handle this situation by always choosing the last one in the CPUID leaves. This is done by letting .detect() returns a priority instead of true/false and just re-using the CPUID leaf where the signature

Author: tha-guest Date: 2006-02-18 16:38:52 +0000 (Sat, 18 Feb 2006) New Revision: 19 Modified: trunk/debian/control trunk/debian/patches/00list trunk/debian/rules trunk/debian/xen-hypervisor-pae.install trunk/debian/xen-hypervisor.install Log: - changed debian/rules to build a pae hypervisor on i386 (has to be done after the "make dist" for the non-pae stuff) - changed

Here's a draft CommonHV spec. It's also on github: https://github.com/amluto/CommonHV So far, this provides a two-way RNG interface, a way to detect it, and a way to detect other hypervisor leaves. The latter is because, after both the enormous public thread and some private discussions, it seems that detection of existing CPUID paravirt leaves is annoying and inefficient. If

Here's a draft CommonHV spec. It's also on github: https://github.com/amluto/CommonHV So far, this provides a two-way RNG interface, a way to detect it, and a way to detect other hypervisor leaves. The latter is because, after both the enormous public thread and some private discussions, it seems that detection of existing CPUID paravirt leaves is annoying and inefficient. If

Package: xen-hypervisor-3.2-1-amd64 Version: 3.2.0-5 Severity: important The hypervisor loads OK but then fails to load my dom0 kernel. I get an erorr message "not an ELF binary" followed after 5s by a hypervisor reboot. /boot/grub/grub.cfg contains: menuentry "Debian GNU/Linux, Xen 3.2-1-amd64, Linux 2.6.22-3-vserver-amd64 (single-user mode)" { set root=(hd0,1)

Package: xen-hypervisor-4.0-amd64 Version: 4.0.1-1 Severity: grave Tags: squeeze sid Justification: renders package unusable -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8

Hi, I noticed that libvirt support the following hypervisors currently: * The KVM/QEMU <http://libvirt.org/drvqemu.html> Linux hypervisor * The Xen <http://libvirt.org/drvxen.html> hypervisor on Linux and Solaris hosts. * The LXC <http://libvirt.org/drvlxc.html> Linux container system * The OpenVZ <http://libvirt.org/drvopenvz.html> Linux container system *

Package: xen-hypervisor-3.0-i386 Version: 3.0.2+hg9697-2 Severity: grave Justification: renders package unusable Hypervisor reboots system after printing: (XEN) Xen trace buffers: disabled >From what I've found online, Xen should start booting the linux kernel at this point, but never does so. I've booted the hypervisor with the options 'noreboot' and 'sync_console' -

Because of legacy-induced blindness, I insisted on separately building the hypervisor.S switcher code (which is mapped at 0xFFC0000 in host and guest). However, the lguest64 patches showed the error of my ways: it has no relocations, so it can be linked into the module like normal then remapped. The only downside is that we can no longer use sizeof(hypervisor_blob), so we need to allocate our

Because of legacy-induced blindness, I insisted on separately building the hypervisor.S switcher code (which is mapped at 0xFFC0000 in host and guest). However, the lguest64 patches showed the error of my ways: it has no relocations, so it can be linked into the module like normal then remapped. The only downside is that we can no longer use sizeof(hypervisor_blob), so we need to allocate our

Package: xen-hypervisor-3.2-1-i386 Version: 3.2-1 Severity: critical Tags: security Justification: DoS of entire system regardless of privilege When running the exploit listed in bug 464953 [1], Xen's memory state becomes corrupted and the hypervisor eventually crashes, taking all of the domU's with it. As such, this breaks operational behaviour, so I have marked this as critical. [1]

On 29/10/14 05:19, Andy Lutomirski wrote: > Here's a draft CommonHV spec. It's also on github: > > https://github.com/amluto/CommonHV > > So far, this provides a two-way RNG interface, a way to detect it, and > a way to detect other hypervisor leaves. The latter is because, after > both the enormous public thread and some private discussions, it seems > that

On 29/10/14 05:19, Andy Lutomirski wrote: > Here's a draft CommonHV spec. It's also on github: > > https://github.com/amluto/CommonHV > > So far, this provides a two-way RNG interface, a way to detect it, and > a way to detect other hypervisor leaves. The latter is because, after > both the enormous public thread and some private discussions, it seems > that

Package: xen Version: 4.8.0-1 Severity: important Starting with 4.8 the xen-hypervisor-4.8* package will contain a grub config file in /etc/default/grub.d/xen.cfg. This will be causing problem when moving to Xen 4.9 because then xen-hypervisor-4.9* will try to install the same file again. This will prevent two versions of the hypervisor to be co-installable. Maybe the solution would be to have a

Add generic virtualization support for pinning the current vcpu to a specified physical cpu. As this operation isn't performance critical (a very limited set of operations like BIOS calls and SMIs is expected to need this) just add a hypervisor specific indirection. Signed-off-by: Juergen Gross <jgross at suse.com> --- V4: move this patch some places up in the series WARN_ONCE in