[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] mmx sse emulation
in an attempt to emulate mmx/sse instructions from within xen, i tried setting EM and NE bit in CR0 to have mmx/sse instructions fault into xen. however, the hvm guest doesn't boot after that. also, i don't get any "device_not_available_fault" any ideas what could be wrong? am i missing something? this is what i've done :- int hvm_set_cr0(unsigned long value) { ... value &= ~HVM_CR0_GUEST_RESERVED_BITS; value |= (X86_CR0_EM | X86_CR0_NE); // EMULATE FPU /* ET is reserved and should be always be 1. */ value |= X86_CR0_ET; ... } I run system with dom0 4 vcpus on 0-2 cpu cores and hvm 1 vcpu on the 3rd cpu core -Ashish On Wed, Nov 5, 2008 at 10:10 AM, mats petersson <mats@xxxxxxxxxxxxxxxxx> wrote: > 2008/11/5 Ashish Bijlani <ashish.bijlani@xxxxxxxxx> >> >> If I'm not wrong, Bochs emulates SSE/MMX instructions and qemu uses >> dynamic translation. Does this mean that I use SSE/MMX emulation code >> from Bochs to put under x86_emulate? or am I missing something? >> Thanks. >> >> On Wed, Nov 5, 2008 at 5:34 AM, Ashish Bijlani <ashish.bijlani@xxxxxxxxx> >> wrote: >> > Hi Andre, >> > >> > You are absolutely right. All hardware virtualization capable machines >> > have recent simd technology built-in. However, I'm just trying to >> > evaluate a case when HVM guests rely on the virtual hardware platform >> > and not on the actual hardware platform. Precisely, what would be the >> > performance gain/loss if hypervisor has to emulate the functionality. > > The performance loss would be HUGE. First of all, you'd fall into the > hypervisor and get back out again, which takes a fair few cycles (like more > than 100x or more that of a single instruction). Then you have to emulate > the actual instruction itself, which will be the small part of the ovehead. > > Many SSE/MMX/3DNow! instructions execute in 1-2 clockcycles. My guess would > be that it would reduce any SSE optimized code to a crawl (like in the order > of 100-1000x slower). Such an application would be much better off running > in x87 mode. > > I was looking at doing SSE/MMX emulation in x86_emulate a long time ago, but > the purpose of that wasn't to emulate SSE/MMX as such, but rather allow > SSE/MMX to access emulated hardware (such as video memory). > > -- > Mats >> >> -Ashish >> >> On Wed, Nov 5, 2008 at 4:59 AM, Andre Przywara <andre.przywara@xxxxxxx> >> wrote: >>> Ashish Bijlani wrote: >>>> >>>> Hi, >>>> >>>> I want to emulate mmx/sse for hvm guests when applications inside hvm >>>> guests are compiled for mmx/sse but the underlying hardware doesn't >>>> support mmx/sse. >>> >>> First: HVM guests require a virtualization capable processor. AFAIK all >>> these processors support at least SSE2 (if not SSE3). So why do you want >>> to >>> emulate these instructions? >>> Second: Applications should check the CPUID bit before using instruction >>> set >>> extension. So, if the host processor does not support MMX/SSE, the guest >>> shouldn't see this bit, too. And I doubt that you are faster with >>> emulating >>> SSE compared to legacy x87-FPU executed natively. >>> >>> So, what is the use-case of your proposal? Or am I missing something >>> here? >>> >>> Regards, >>> Andre. >>> >>>> What is the best place to do this? i'm looking at >>>> >>>> x86_emulate but i dunno if that is the best place to put the emulation >>>> layer. any suggestions?? also, currently movq emulation is present in >>>> x86_emulate for handling mmio. however, i realized that get_fpu fails >>>> if the hardware doesn't have mmx capability. is it true or am i >>>> missing something here? >>>> >>>> Thanks, >>>> Ashish >>> >>> -- >>> Andre Przywara >>> AMD-OSRC (Dresden) >>> Tel: x84917 >>> >>> >> > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |