Ricardo Neri ricardo.neri-calderon@linux.intel.com writes:
On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote:
Ricardo Neri ricardo.neri-calderon@linux.intel.com writes:
On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote:
30.03.2017 08:14, Ricardo Neri пишет: In fact, smsw has an interesting property, which is that no one will ever want to disable its in-kernel emulation to provide its own. So while I'll try to estimate its usage, emulating it in kernel will not be that problematic in either case.
Ah good to know!
As for protected mode, if wine only needs sgdt/sidt, then again, no one will want to disable its emulation. Not the case with sldt, but AFAICS wine doesn't need sldt, and so we can leave sldt without a fixups. Is my understanding correct?
This is my understanding as well. I could not find any use of sldt in wine. Alexandre, would you mind confirming?
Some versions of the Themida software protection are known to use sldt as part of the virtual machine detection code [1]. The check currently fails because it expects the LDT to be zero, so the app is already broken, but sldt segfaulting would still cause a crash where there wasn't one before.
However, I'm only aware of one application using this, and being able to catch and emulate sldt ourselves would actually give us a chance to fix this app in newer Wine versions, so I'm not opposed to having it segfault.
Great! Then this is in line with what we are aiming to do with dosemu2: not emulate str and sldt.
In fact it would be nice to be able to make sidt/sgdt/etc. segfault too. I know a new syscall is a pain, but as far as Wine is concerned, being able to opt out from any emulation would be potentially useful.
I see. I guess for now there should not be a problem with emulating sidt/sgdt/smsw, right? In this way we don't break current versions of winehq and programs using it. In a phase two we can introduce the syscall so that kernel fixups can be disabled. Does this make sense?
Yes, that makes sense.