Hi Keir, so far the convention seems to be to assume that guest attempts to execute instructions not supported by the underlying CPU would never make it into the emulator. Is that really correct (in particular in the context of real mode emulation, where it''s not just single instructions that get emulated)?>From earlier work on the emulation code I seem to recall that it''s mainlythe testing code that didn''t like use of cpu_has_xyz in conditionals. I would suppose that simply adding respective feature detection (and boolean variables) to the testing code should get us around this problem. Or would you see any better alternative? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/11/2011 13:03, "Jan Beulich" <JBeulich@suse.com> wrote:> Hi Keir, > > so far the convention seems to be to assume that guest attempts to > execute instructions not supported by the underlying CPU would never > make it into the emulator. Is that really correct (in particular in the > context of real mode emulation, where it''s not just single instructions > that get emulated)? > > From earlier work on the emulation code I seem to recall that it''s mainly > the testing code that didn''t like use of cpu_has_xyz in conditionals. I > would suppose that simply adding respective feature detection (and > boolean variables) to the testing code should get us around this > problem. Or would you see any better alternative?I''m fine to have further feature checks in the emulator, but I would like to keep the emulator core clean. And indeed the emulator probably ought to act based on features advertised to the *guest* rather than the *host*? So, properly, I think the fact we already have a cpuid callback ought to be sufficient to implement all the cpu_has functionality that the emulator could want, perhaps hidden behind some helper/abstraction functions/macros. The question would then be whether that is fast enough. My guess is it would be, and I''d rather do it that way, or close to that way, in the first instance at least, and then optimise later if we see the need. -- Keir> Jan >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 15.11.11 at 14:30, Keir Fraser <keir@xen.org> wrote: > On 15/11/2011 13:03, "Jan Beulich" <JBeulich@suse.com> wrote: > >> Hi Keir, >> >> so far the convention seems to be to assume that guest attempts to >> execute instructions not supported by the underlying CPU would never >> make it into the emulator. Is that really correct (in particular in the >> context of real mode emulation, where it''s not just single instructions >> that get emulated)? >> >> From earlier work on the emulation code I seem to recall that it''s mainly >> the testing code that didn''t like use of cpu_has_xyz in conditionals. I >> would suppose that simply adding respective feature detection (and >> boolean variables) to the testing code should get us around this >> problem. Or would you see any better alternative? > > I''m fine to have further feature checks in the emulator, but I would like to > keep the emulator core clean. And indeed the emulator probably ought to act > based on features advertised to the *guest* rather than the *host*?That''s a good point.> So, properly, I think the fact we already have a cpuid callback ought to be > sufficient to implement all the cpu_has functionality that the emulator > could want, perhaps hidden behind some helper/abstraction functions/macros.Which may make it necessary to add cpuid callbacks to all emulator users (seems like only hvm currently has one). But it indeed looks like the right route to go, so I''ll look into doing so. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/11/2011 13:53, "Jan Beulich" <JBeulich@suse.com> wrote:>> So, properly, I think the fact we already have a cpuid callback ought to be >> sufficient to implement all the cpu_has functionality that the emulator >> could want, perhaps hidden behind some helper/abstraction functions/macros. > > Which may make it necessary to add cpuid callbacks to all emulator > users (seems like only hvm currently has one). But it indeed looks like > the right route to go, so I''ll look into doing so.Yes, probably. The CPUID emulation backend is similar across both PV and HVM, so there shouldn''t be much per-user shimming to be done. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel