Hi,
any comment/review on this patch ?
Is there any interest for Win32 ? I have patches (serial input from
console) to port to the current version.
TIA,
Tristan.
On Jul 3, 2007, at 3:03 PM, Tristan Gingold wrote:
this patch fixes two minors issue for cygwin:
* --disable-kqemu didn't work
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/12 09:03:30
Modified files:
. : qemu-doc.texi qemu-tech.texi
Log message:
More documentation bits, from Stefan Weil.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/12 09:29:18
Modified files:
. : Makefile.target configure
Log message:
Fix configure for cygwin, by Tristan Gingold.
CVSWeb URLs:
Tristan Gingold wrote:
Hi,
any comment/review on this patch ?
Is there any interest for Win32 ? I have patches (serial input from
console) to port to the current version.
Committed.
Thiemo
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/12 10:05:07
Modified files:
. : gdbstub.c
Log message:
Improve handling of gdb's single-step / continue arguments.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/12 10:59:21
Modified files:
audio : alsaaudio.c audio.c audio_int.h
hw : pxa2xx.c
linux-user : syscall.c
Log message:
Spelling fix, by Stuart
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/12 11:02:47
Modified files:
linux-user : signal.c
Log message:
Sigio fd passing, by Alexander Graf.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/12 11:06:53
Modified files:
linux-user : syscall.c
Log message:
Tkill support, by Stuart Anderson.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/07/12 11:32:22
Modified files:
target-ppc : helper.c
Log message:
Fix crash in set registers in PPC gdb-stub, by Jason Wessel.
CVSWeb URLs:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It shouldn't happen. For example, both VirtualPC and VirtualBox pause
all VMs, and gray their displays when something like that
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It shouldn't happen. For example, both VirtualPC and VirtualBox pause
all VMs, and gray their displays
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It shouldn't happen. For example, both
Paul Brook wrote:
Besides, most
filesystems reserve some space for the superuser, now unless there's a
cross-platform way to figure out just how much space that is, you'd still
be getting errors despite having 5~10% of the filesystem technically
free.
Qemu might freeze the guest when it
Daniel P. Berrange wrote:
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing .VMDK hard disk.
It
Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
second or wait for user input on the monitor.
Better would IMHO be to report an IO error to the guest and allow that to
decide what to do. If you're bothered about robustness and reliability
then arbitrarily
Paul Brook wrote:
Qemu might freeze the guest when it gets -ENOSPC, and say, retry every
second or wait for user input on the monitor.
Better would IMHO be to report an IO error to the guest and allow that to
decide what to do. If you're bothered about robustness and reliability
then
On 12/07/07, Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Thu, Jul 12, 2007 at 07:12:58PM +0300, Avi Kivity wrote:
Mike Swanson wrote:
On Wednesday 11 July 2007 08:19:48 Alexey Eremenko wrote:
Problem 1:
When Host HDD is full, all guests simply crash. Tried with dynamically
growing
Pause VMs is the only realistic option. This is the correct option,
because it ensures that guest is still alive.
Other options might crash the guest, like Windows BSOD. Worse yet is
that guest may think that it's hard disk is bad, and will start
marking it's sectors as bad-blocks.
When the VM
Hello group,
I have two questions, both regarding the virtual-physical translation of
addresses (all in the virtual machine context).
1
Can somebody tell me if the program counter value available in the following
snippet from target-i386/translate.c
is virtual or physical? I learnt it may be
19 matches
Mail list logo