R. Armiento wrote:
Is this hack really 'safe'? I don't claim to know much about modern
x86 instructions, but some googling tells me that mwait is supposed
to wake on a monitored memory write (but is allowed to wake up
earlier, hence it is acceptable but CPU consuming to emulate it
with a
Hi!This updated patch against current CVS implements TCP segmentation offloading for RTL8139 in C+ mode.I fixed a couple of problems in implementation (wrong sequence number calculation), and now TCP performance seem to be normal.
Dependency on slirp.h header is now gone.Again tested with linux
R. Armiento wrote:
Couldn't there be situations where someone depends on mwait waking up
without there being an event that wakes hlt? Or are we sure qemu's hlt
will happen to wake up anyway?
Joachim Henke wrote:
Currently the Linux kernel simply uses monitor/mwait as a faster 'hlt'
Problem is, at the moment I've no idea, how we could achieve this memory
monitoring in a safe and simple way in user space.
I'm trying to read up on monitor and mwait. Apparently mwait puts the
processor in low-power wait mode, waiting for a memory write in some
select area defined by
Worse, the guest might decide to swap out a page that's already
swapped in by the host, forcing it to be read in again only to be
immediately written out to disk by the guest :-(
...unless the guest's disk I/O is with simulated DMA or recognisable
block-copy instruction sequences, and
Ok, I forgot about external kernel modules or patches, as I don't use
any. But in plain Linux 2.6.17 mwait is only used in the function
mwait_idle()
R. Armiento wrote:
But I just don't see how you can postulate that mwait is not used
anywhere else in the Linux kernel? There are many kernel
Joachim Henke wrote:
Currently the Linux kernel simply uses monitor/mwait as a faster
'hlt' replacement, so it should be safe there. I don't know about
other guest OSs. Anyway, I proposed this hack only as a quick
solution for local usage.
As long as there's only one CPU and 'mwait'
R. Armiento wrote:
I'm not sure if I have understood all sources from where such a
memory write can come from while the processor is asleep. One
source, I suppose, is from other processors in an SMP setup? Another
source may be DMA? Does this mean that it is safe to emulate wmait
as hlt if
Paul Brook wrote:
qemu hardware does support DMA, but I don't think this matters.
By my reading DMA writes don't need to wake mwait.
The exact wording is store operation, which I'd expect to mean
execution of a store instruction (by a different CPU).
Hmm. x86 CPUs snoop writes by DMA as well
I'm running BasicLinux3.4(Baslin3.4-qemu.img kernel 2.2.26) on Win98,and I receive quite often this following messages:
probable hardware bug: clock timer configuration lost - probably a VIA686a. probable hardware bug: restoring chip configuration.
Does anyone know to fix this problem?Thanks!
On 7/8/06, Oliver Gerlich [EMAIL PROTECTED] wrote:
Is wxC still under active development? The CVS version seems to be quite
old, and I also couldn't find any documentation.
Well it wouldn't be the first unmaintained batch of code added to
QEMU... Slirp is the example that comes to mind. In
On Sun, Jul 09, 2006 at 05:03:12PM -0700, John R. wrote:
On 7/8/06, Oliver Gerlich [EMAIL PROTECTED] wrote:
Is wxC still under active development? The CVS version seems to be quite
old, and I also couldn't find any documentation.
Well it wouldn't be the first unmaintained batch of code
On Sun, 09 Jul 2006 17:56:31 +0200, 赵刚 [EMAIL PROTECTED] wrote:
I'm running BasicLinux3.4(Baslin3.4-qemu.img kernel 2.2.26) on Win98
,and I receive quite often this following messages:
probable hardware bug: clock timer configuration lost - probably a
VIA686a.
probable hardware bug:
13 matches
Mail list logo
