[Qemu-devel] Ping: PATCH: fix configure for cygwin
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 for this configuration (because overridden) * -mno-cygwin was missing in the final link. Tristan. qemu-mingw.diff
[Qemu-devel] qemu qemu-doc.texi qemu-tech.texi
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: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.154r2=1.155 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-tech.texi?cvsroot=qemur1=1.12r2=1.13
[Qemu-devel] qemu Makefile.target configure
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: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.186r2=1.187 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.148r2=1.149
Re: [Qemu-devel] Ping: PATCH: fix configure for cygwin
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
[Qemu-devel] qemu gdbstub.c
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: http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemur1=1.60r2=1.61
[Qemu-devel] qemu audio/alsaaudio.c audio/audio.c audio/audi...
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 Brady. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/audio/alsaaudio.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/audio/audio.c?cvsroot=qemur1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/qemu/audio/audio_int.h?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.113r2=1.114
[Qemu-devel] qemu/linux-user signal.c
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: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.38r2=1.39
[Qemu-devel] qemu/linux-user syscall.c
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: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.114r2=1.115
[Qemu-devel] qemu/target-ppc helper.c
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: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.48r2=1.49
Re: [Qemu-devel] Crash: When Host HDD is full
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 happens. IMO, it's a non-issue; you probably shouldn't be letting your filesystems to become full in the first place, much less running VMs on it. 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.
Re: [Qemu-devel] Crash: When Host HDD is full
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 when something like that happens. IMO, it's a non-issue; you probably shouldn't be letting your filesystems to become full in the first place, much less running VMs on it. Well, he shouldn't, but neither should qemu crash or corrupt data. 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 gets -ENOSPC, and say, retry every second or wait for user input on the monitor. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Crash: When Host HDD is full
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 VirtualPC and VirtualBox pause all VMs, and gray their displays when something like that happens. IMO, it's a non-issue; you probably shouldn't be letting your filesystems to become full in the first place, much less running VMs on it. Well, he shouldn't, but neither should qemu crash or corrupt data. It should be propagating any IO errors in the host back up to the guest OS as IDE errors. The guest OS will see these and (in the case of Linux) take the filesystem offline. There should be no crash or data corruption. While any outstanding writes will not have been flushed with any reasonable filesystem it will recover upon reboot, either by fsck, or trivially recovering the journal maintaining filesystem integrity. Potentially ENOSPC could be handled as a special case by pausing the guest, but in general I/O errors can be propagated back to guest for handling (even if the guest merely takes things ofline). Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] Crash: When Host HDD is full
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 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 stopping the guest is not acceptable behaviour. There's no guarantee that space will become available in a finite timeframe. I've considered that, and I'm not sure. You will likely get a storm of I/O errors on ENOSPC; with several ways for disaster to strike: - the guest doesn't handle I/O errors well, and keeps writing. some of the writes are overwrites so they hit the disk and data is corrupted - the guest decides the disk is bad because it has too many errors and initiates some recovery procedure Stopping the guest at least guarantees nothing unexpected happens. If it's part of a managed solution we can output a message to the monitor which eventually finds its way to the operator. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Crash: When Host HDD is full
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 shouldn't happen. For example, both VirtualPC and VirtualBox pause all VMs, and gray their displays when something like that happens. IMO, it's a non-issue; you probably shouldn't be letting your filesystems to become full in the first place, much less running VMs on it. Well, he shouldn't, but neither should qemu crash or corrupt data. It should be propagating any IO errors in the host back up to the guest OS as IDE errors. The guest OS will see these and (in the case of Linux) take the filesystem offline. There should be no crash or data corruption. While any outstanding writes will not have been flushed with any reasonable filesystem it will recover upon reboot, either by fsck, or trivially recovering the journal maintaining filesystem integrity. Potentially ENOSPC could be handled as a special case by pausing the guest, but in general I/O errors can be propagated back to guest for handling (even if the guest merely takes things ofline). I agree about general I/O errors. However ENOSPC cannot happen for disks and should not be converted into an I/O error. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Crash: When Host HDD is full
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 stopping the guest is not acceptable behaviour. There's no guarantee that space will become available in a finite timeframe. I've considered that, and I'm not sure. You will likely get a storm of I/O errors on ENOSPC; with several ways for disaster to strike: - the guest doesn't handle I/O errors well, and keeps writing. some of the writes are overwrites so they hit the disk and data is corrupted If an guest OS ignores IO write errors it's just plain broken. - the guest decides the disk is bad because it has too many errors and initiates some recovery procedure Stopping the guest at least guarantees nothing unexpected happens. If it's part of a managed solution we can output a message to the monitor which eventually finds its way to the operator. I don't buy this argument. If you don't want unexpected things to happen then the solution is simple: Make sure you never run out of disk space. The fact is that your (virtual) disk *is* broken at this point. The guest OS is in a much better position to decide on an appropriate course of action, either by retrying or some other recovery mechanism. There are various error contitions that could be used, for example write-protect. Paul
Re: [Qemu-devel] Crash: When Host HDD is full
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 arbitrarily stopping the guest is not acceptable behaviour. There's no guarantee that space will become available in a finite timeframe. I've considered that, and I'm not sure. You will likely get a storm of I/O errors on ENOSPC; with several ways for disaster to strike: - the guest doesn't handle I/O errors well, and keeps writing. some of the writes are overwrites so they hit the disk and data is corrupted If an guest OS ignores IO write errors it's just plain broken. Linux 2.4 ignores IO write errors under certain conditions. Yes, it's broken. But you're making the user suffer for this brokenness even if the only thing wrong is a temporary shortage of disk space. - the guest decides the disk is bad because it has too many errors and initiates some recovery procedure Stopping the guest at least guarantees nothing unexpected happens. If it's part of a managed solution we can output a message to the monitor which eventually finds its way to the operator. I don't buy this argument. If you don't want unexpected things to happen then the solution is simple: Make sure you never run out of disk space. That's unrealistic, at least for the casual user running qemu. A managed solution can probably work around this. Qemu should be more user friendly. The fact is that your (virtual) disk *is* broken at this point. The guest OS is in a much better position to decide on an appropriate course of action, either by retrying or some other recovery mechanism. I don't see why it is broken. The disk contents have not changed since after the last successful write. Once you free some space you can continue writing. Note that a recovery mechanism that involves writing will likely fail as well, possibly corrupting the disk in the process. There are various error contitions that could be used, for example write-protect. The guest would most likely be surprised at getting a write-protect error on its hard disk, and then the disk *would* be broken. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Crash: When Host HDD is full
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 .VMDK hard disk. It shouldn't happen. For example, both VirtualPC and VirtualBox pause all VMs, and gray their displays when something like that happens. IMO, it's a non-issue; you probably shouldn't be letting your filesystems to become full in the first place, much less running VMs on it. Well, he shouldn't, but neither should qemu crash or corrupt data. It should be propagating any IO errors in the host back up to the guest OS as IDE errors. Here's a patch attempting to do that which I posted back when I was really annoyed at almost losing my data because of QEMU not propagating the errors: http://lists.gnu.org/archive/html/qemu-devel/2005-12/msg00275.html . I agree that this should be the correct behavior but there was no agreement over this when it was discussed on IRC. (I don't know if the patch was correct though, it was a bit of black magic for me at the time) Cheers, Andrew
Re: [Qemu-devel] Crash: When Host HDD is full
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 is paused, the user may take action to free some disk space and unpause guest manually. -- -Alexey Eremenko Technologov
[Qemu-devel] address translation
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 virtual, in which case is there a
way to extract the physical address corresponding to the
virtual address, or if it is physical, then is there a way to translate to
its virtual address (within the virtual machine context)?
/* convert one instruction. s-is_jmp is set if the translation must
be stopped. Return the next pc value */
static target_ulong disas_insn(DisasContext *s, target_ulong pc_start)
{
int b, prefixes, aflag, dflag;
int shift, ot;
int modrm, reg, rm, mod, reg_addr, op, opreg, offset_addr, val;
target_ulong next_eip, tval;
int rex_w, rex_r;
s-pc = pc_start; // This s-pc is what I am using to extract all
executed PC values
2
Second question I have is - Within the functions from target-i386/ops_mem.h
for example,
void OPPROTO glue(glue(op_ldub, MEMSUFFIX), _T0_A0)(void)
{
T0 = glue(ldub, MEMSUFFIX)(A0);
}
Is A0 the physical address? or is it virtual?
And how to I translate from one to another in either case?
Thanks in advance.
-Shashi.
