similar to: More virtio users

Has anyone gotten this working? It seems it is a toolkit to allow guest OSes to have native speed OpenGL rendering. It might it be a good inclusion for Indiana. (To enable people to test it out in a VM.) http://www.cs.toronto.edu/~andreslc/vmgl/ --Brian P.S - The site said it is running on OpenSolaris _______________________________________________ indiana-discuss mailing list

hi, is there any plan to package and/or include VMGL in centos/fedora: http://www.cs.toronto.edu/~andreslc/xen-gl/ -- Levente "Si vis pacem para bellum!"

Hello. I am just looking around today for the new 3D virtualization availability with VMGL. http://www.cs.toronto.edu/~andreslc/xen-gl/ http://kvm.qumranet.com/kvmwiki/HOWTO_VMGL And the conversation in the virtualbox forum here: http://forums.virtualbox.org/viewtopic.php?t=16&postdays=0&postorder=asc&start=0 There talk about VMGL, wine, and a project that i didnt know:

Hello, I used a ScienticLinux 5.0 distro (mimics RedHat 5.0 but merged the Server and Enterprise versions) in a x86_64 arch. I ran into a problem, because while I can have X in the normal kernel, the Xen kernel, when I boot in dom0 is in text mode and can''t load the Nvidia module. This is because Nvidia does not support Xen. There seems to be some patches for other distros (Suse,

Zhang, Xiantao wrote: > Hi Folks, > We are working on enabling KVM support on IA64 platform, and now > Linux, Windows guests get stable run and achieve reasonable performance > on KVM with Open GFW. But you know, the current KVM only considers x86 > platform, and is short of cross-architecture framework. Currently, we > have a proposal for KVM source layout to accommodate new

Zhang, Xiantao wrote: > Hi Folks, > We are working on enabling KVM support on IA64 platform, and now > Linux, Windows guests get stable run and achieve reasonable performance > on KVM with Open GFW. But you know, the current KVM only considers x86 > platform, and is short of cross-architecture framework. Currently, we > have a proposal for KVM source layout to accommodate new

The network-bridge script fails when setting a few sysctls which are only available if ebtables is present in the host kernel. Fix by ignoring the return value of the sysctl command. Signed-off-by: Avi Kivity <avi@qumranet.com> Index: xen/tools/examples/network-bridge =================================================================== --- xen/tools/examples/network-bridge (revision 991)

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

The 9p-virtio transport does zero copy on things larger than 1024 bytes in size. It accomplishes this by returning the physical addresses of pages to the virtio-pci device. At present, the translation is usually a bit shift. However, that approach produces an invalid page address when we read/write to vmalloc buffers, such as those used for Linux kernle modules. This causes QEMU to die printing:

The 9p-virtio transport does zero copy on things larger than 1024 bytes in size. It accomplishes this by returning the physical addresses of pages to the virtio-pci device. At present, the translation is usually a bit shift. However, that approach produces an invalid page address when we read/write to vmalloc buffers, such as those used for Linux kernle modules. This causes QEMU to die printing:

Hi folks, Xen''s qemu-dm version has a ''-vncunused'' command line switch which asks the internal vnc server to pick any unused tcp port to listen on. The actual port is communicated to the outside world via xenstore. I''m looking for a reasonable way to implement that functionality in upstream qemu. First, I think it shouldn''t be a separate command

On 19/10/10 11:39, Avi Kivity wrote: > On 10/19/2010 12:31 PM, Ian Molton wrote: >>> 2. should start with a patch to the virtio-pci spec to document what >>> you're doing >> >> Where can I find that spec? > > http://ozlabs.org/~rusty/virtio-spec/ Ok, but I'm not patching that until theres been some review. There are links to the associated qemu and

On 19/10/10 11:39, Avi Kivity wrote: > On 10/19/2010 12:31 PM, Ian Molton wrote: >>> 2. should start with a patch to the virtio-pci spec to document what >>> you're doing >> >> Where can I find that spec? > > http://ozlabs.org/~rusty/virtio-spec/ Ok, but I'm not patching that until theres been some review. There are links to the associated qemu and

https://bugs.freedesktop.org/show_bug.cgi?id=92297 Bug ID: 92297 Summary: dithering detected incorrectly Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Driver/nouveau Assignee: nouveau at

The main change from the patches I sent out earlier this week is support for guests that use the PIC. A callback for PIC irq ack handling is also introduced. Currently, there's no mechanism to register/unregister callers to the irq ack callbacks, but they can be added when there's more than one user for the functionality. Please review.

The main change from the patches I sent out earlier this week is support for guests that use the PIC. A callback for PIC irq ack handling is also introduced. Currently, there's no mechanism to register/unregister callers to the irq ack callbacks, but they can be added when there's more than one user for the functionality. Please review.

The following makes 'x86info -r' dump hypervisor leaf cpu ids (for kvm this is signature+features) when running in a vm. On the guest we see the signature and the features: eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 Hypervisor flag is checked to avoid output changes when

The following makes 'x86info -r' dump hypervisor leaf cpu ids (for kvm this is signature+features) when running in a vm. On the guest we see the signature and the features: eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000 Hypervisor flag is checked to avoid output changes when