One of my collegues tried to run a kernel optimized for K7 in HVM and it fell over because it tried to do a MOVQ instruction from somewhere in mmio-space. It turned out to be pretty trivial to patch in the instruction length and decode part of understanding this type of instruction, but the MMX registers (mm0 - mm7) are not available to the hypervisor without a lot of munging around (I think calling FPU-save would do it). It''s worth keeping in mind that the standard kernel that is supplied with most distro''s isn''t using any MMX or SSE instructions at all, and the best option for accessing larger blocks of MMIO space is actually REP MOVS instructions - but it''s also not fair to stop unmodified kernels from running on the system, even if they use MMX or SSE instructions, right? So, this makes two questions: 1. Is anyone else working on anything like this (expanding the valid instructions that can access memory-mapped IO to include either SSE or MMX instructions?) 2. Does anyone have a hint on how we best get the MMX and SSE registers so that they can be accessed in hvm/platform.c? Gratefully waiting for replies... -- Mats _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 20 Apr 2006, at 16:37, Petersson, Mats wrote:> 1. Is anyone else working on anything like this (expanding the valid > instructions that can access memory-mapped IO to include either SSE or > MMX instructions?)I don''t think so. Best would be to move all HVM I/O emulation to the common Xen emulator (x86_emulate.c) and add the needed emulation there. Either way I expect that we will only need to emulate a very few SSE instructions (I expect this case is the result of an optimised memset()?).> 2. Does anyone have a hint on how we best get the MMX and SSE registers > so that they can be accessed in hvm/platform.c?Call unlazy_fpu(current) and then read/write the appropriate fields in current->arch.guest_context.fpu_ctxt. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Keir Fraser > Sent: 20 April 2006 17:00 > To: Petersson, Mats > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] Support for SSE/MMX instructions. > > > On 20 Apr 2006, at 16:37, Petersson, Mats wrote: > > > 1. Is anyone else working on anything like this (expanding > the valid > > instructions that can access memory-mapped IO to include > either SSE or > > MMX instructions?) > > I don''t think so. Best would be to move all HVM I/O emulation > to the common Xen emulator (x86_emulate.c) and add the needed > emulation there.I''ve looked a little bit at doing that - and it would probably make sense to merge x86_emulate and the hvm handle_mmio() code, but there are some stuff done in the handle_mmio() code that isn''t done in x86_emulate. I''ll look a little further to see if I can make something out of it [it''s clearly not very clever to have two pieces of code that decodes/emulates instructions!]> Either way I expect that we will only need to emulate a very > few SSE instructions (I expect this case is the result of an > optimised memset()?).I would expect to only see very few operations: MOVQ, MOVDQ[AU], MOVNTQ, MOVNTDQ[AU]. And, yes in conjunction with memset/memcpy and closely related/in-lined or specialized versions [I know 3DLabs use combinations of regular and SSE instructions to copy data in the OpenGL library for example, and although that gets written to regular memory, not MMIO, I can certainly imagine that someone might use the same type of mix for other types of operations]. For MMIO operations, I would say that the majority would probably be copying data to or from someplace to an memory mapped IO location. I''ve very rarely seen code do memset on memory-mapped IO locations (but I guess a "clear-screen" in the form of memset((void *)0xb8000, 0, 4000); would be such a case...)> > > 2. Does anyone have a hint on how we best get the MMX and SSE > > registers so that they can be accessed in hvm/platform.c? > > Call unlazy_fpu(current) and then read/write the appropriate fields in > current->arch.guest_context.fpu_ctxt.That''s what I thought - but I wanted to make sure... ;-) -- Mats> > -- Keir > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21 Apr 2006, at 14:26, Petersson, Mats wrote:>> I don''t think so. Best would be to move all HVM I/O emulation >> to the common Xen emulator (x86_emulate.c) and add the needed >> emulation there. > > I''ve looked a little bit at doing that - and it would probably make > sense to merge x86_emulate and the hvm handle_mmio() code, but there > are > some stuff done in the handle_mmio() code that isn''t done in > x86_emulate. I''ll look a little further to see if I can make something > out of it [it''s clearly not very clever to have two pieces of code that > decodes/emulates instructions!]The main downsides to moving to x86_emulate are that it looks like movs emulation would be slower (but we can optimise that if it matters), and that you''ll also need a copy of the emulator in qemu-dm (since there''s no split decode/emulation -- but I consider that a good thing). Certainly in terms of range of instructions emulated, x86_emulate wins by far. It pains me to see new instructions trickling into the HVM emulator(s)... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel