On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote: > Ricardo Neri <ricardo.neri-calderon@xxxxxxxxxxxxxxx> writes: > > > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: > >> 30.03.2017 08:14, Ricardo Neri пишет: > >> >>>> But at least dosemu implements it, so probably it is needed. > >> >>> Right. > >> >>> > >> >>>> Of course if it is used by one of 100 DOS progs, then there > >> >>>> is an option to just add its support to dosemu2 and pretend > >> >>>> the compatibility problems did not exist. :) > >> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and > >> >>> emulating it in the kernel? > >> >> Yes, that would be optimal if this does not severely break > >> >> the current setups. If we can find out that smsw is not in > >> >> the real use, we can probably do exactly that. > >> >> But other > >> >> instructions are not in real use in v86 for sure, so I > >> >> wouldn't be adding the explicit test-cases to the kernel > >> >> that will make you depend on some particular behaviour > >> >> that no one may need. > >> >> My objection was that we shouldn't > >> >> write tests before we know exactly how we want this to work. > >> > OK, if only SMSW is used then I'll keep the emulation for SMSW only. > >> 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? Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
