search for: hypervisors

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

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

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 were found as the priority (or 1 if it...

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 were found as the priority (or 1 if it...

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 were found as the priority (or 1 if it...

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

...ion of existing CPUID paravirt leaves is annoying and inefficient. If we're going to define some cross-vendor CPUID leaves, it seems like it would be useful to offer a way to quickly enumerate other leaves. I've been told the AMD intends to update their manual to match Intel's so that hypervisors can use the entire 0x4F?????? CPUID range. I have intentionally not fixed an MSR value for the RNG because the range of allowed MSRs is very small in both the Intel and AMD manuals. If any given hypervisor wants to ignore that small range and advertise a higher-numbered MSR, it is welcome to, but...

...ion of existing CPUID paravirt leaves is annoying and inefficient. If we're going to define some cross-vendor CPUID leaves, it seems like it would be useful to offer a way to quickly enumerate other leaves. I've been told the AMD intends to update their manual to match Intel's so that hypervisors can use the entire 0x4F?????? CPUID range. I have intentionally not fixed an MSR value for the RNG because the range of allowed MSRs is very small in both the Intel and AMD manuals. If any given hypervisor wants to ignore that small range and advertise a higher-numbered MSR, it is welcome to, but...

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/drvopen...

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]

...t leaves is annoying and > inefficient. If we're going to define some cross-vendor CPUID leaves, > it seems like it would be useful to offer a way to quickly enumerate > other leaves. > > I've been told the AMD intends to update their manual to match Intel's > so that hypervisors can use the entire 0x4F?????? CPUID range. I have > intentionally not fixed an MSR value for the RNG because the range of > allowed MSRs is very small in both the Intel and AMD manuals. If any > given hypervisor wants to ignore that small range and advertise a > higher-numbered MSR, i...

...t leaves is annoying and > inefficient. If we're going to define some cross-vendor CPUID leaves, > it seems like it would be useful to offer a way to quickly enumerate > other leaves. > > I've been told the AMD intends to update their manual to match Intel's > so that hypervisors can use the entire 0x4F?????? CPUID range. I have > intentionally not fixed an MSR value for the RNG because the range of > allowed MSRs is very small in both the Intel and AMD manuals. If any > given hypervisor wants to ignore that small range and advertise a > higher-numbered MSR, i...

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