Re: [Qemu-devel] qemu old releases ?
S.P.T.Krishnan wrote: Hi, Is there an archive download site for all the qemu old versions ? I need one of the old verions for testing purposes. You could always download it by CVS tag revision.. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wipe patch
andrzej zaborowski wrote: On 02/08/06, Brad Campbell <[EMAIL PROTECTED]> wrote: ZIGLIO, Frediano, VF-IT wrote: > Hi, > well, this is not a definitive patch but it works. The aim is to be > able to wipe the disk without allocating entire space. When you wipe a > disk the program fill disk with zero bytes so disk image increase to > allocate all space. This just patch detect null byte writes and do not > write all zero byte clusters. > I've been giving this some pretty heavy testing over the last week and can say I've not noticed any negative performance impact or any other adverse side effects, not to mention the speedup when doing re-packing (which I do fairly regularly on both ext3 and ntfs guest filesystems). While I'm here does anyone know of a simple program, either dos or linux based for wiping unused space on fat filesystems? The only ones I've found so far have been windows based. I don't know if you mean just zeroing unused parts or reordering the data and stuff like defragmentation. If you mean the former, there's a universal method: dd if=/dev/zero of=xxx; rm xxx where xxx is a path to a new file on the filesystem, which must be mounted. It will creata a zero filled file there, which will fill all It would be wise to sync as well, to ensure the zeros are actually written and not stored in cache where the rm would remove them: dd if=/dev/zero of=xxx; sync; rm xxx availiable space, and remove the file afterwards. I used this when I needed to send filesystem images through internet so that they compressed well. If you add dd= it might take less time to write the file. Regards, begin:vcard fn:Nigel Horne n:Horne;Nigel org:NJH Music email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE url:http://www.bandsman.co.uk version:2.1 end:vcard ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to Simulate hardware that counts scanlines?
The next release of QEMU is likely to have cycle exact emulation and delivery of interrupts in the middle of a basic block. Regards, Fabrice. Armistead, Jason wrote: Steve Ellenoff wrote: You misunderstand, I have no control over the running program. I didn't write it, I don't have source code, and I surely wouldn't have used a polling mechanism for determining the vblank as you suggested. My problem is that I wish to run this program through qemu. I've made a bunch of hardware specific additions to qemu to emulate the specific hardware this program runs on. I'm just not sure the best way to simulate the scanline counting the hardware does. Seems nobody here has any ideas either, which is kind of hard to believe. I don't know if this would work, but one idea I had was to divide up the gui timer into 260 slices (that's the # of scanlines the hardware expects), and simply update the hardware register that counts the scanlines this way. Does anyone thing that's the way to go, or if there's a better way? As I see it, one of the problems in Steve's scenario is that QEMU does dynamic translations based on blocks of code, and the interrupts or changes to emulated hardware state are delivered only at the end of the execution of an entire basic block. While this might be adequate for an operating system which cares for the most part very little about real world timing, it may not be sufficient for every case where you want to do an emulation of a processor in an embedded device or a curious non-standard PC like Steve's. I think that's why the game system emulators MAME and MESS are perhaps more akin to what he's wanting to do, in that they are able to deliver interrupts in exactly the same way as the real CPU sees them i.e. at the end of execution of the current instruction, and they consider instruction execution timing to maintain an accurate internal time base, independent from what the real world outside is doing. On most modern fast PC CPUs, they can easily emulate the older arcade game or computer system hardware with plenty of horsepower to spare, and so it appears realtime, synchronised via RDTSC or similar. I guess if you ran them on an underperforming PC like an old 486 or early Pentium, you may see things go at less than real speed. Maybe I'm totally off the mark, but at least that's how I read the QEMU docs relating to hardware interrupts http://www.qemu.org/qemu-tech.html#SEC18 and the preceding sections about the way instruction blocks are translated and executed. I'm sure Fabrice and others can shoot me down if needs be ... Cheers Jason ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu old releases ?
S.P.T.Krishnan wrote: > Hi, > > Is there an archive download site for all the qemu old versions ? > I need one of the old verions for testing purposes. You can always checkout qemu's cvs repository for older versions. Older distribution tarballs should be avialiable on package mirrors somewhere on the net (googling for the filename should return some useful results). With regards, Jan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] Wipe patch
> > ZIGLIO, Frediano, VF-IT wrote: > > Hi, > > well, this is not a definitive patch but it works. The > aim is to be > > able to wipe the disk without allocating entire space. When > you wipe a > > disk the program fill disk with zero bytes so disk image increase to > > allocate all space. This just patch detect null byte writes > and do not > > write all zero byte clusters. > > > > I've been giving this some pretty heavy testing over the last > week and can say I've not noticed any > negative performance impact or any other adverse side > effects, not to mention the speedup when doing > re-packing (which I do fairly regularly on both ext3 and ntfs > guest filesystems). > > While I'm here does anyone know of a simple program, either > dos or linux based for wiping unused > space on fat filesystems? The only ones I've found so far > have been windows based. > > This patch now conflicts pretty heavily with the new AIO > changes it would seem. Further > investigation required. > > Ta, > Brad Here you are updated patch. Current CVS seems to not compile on my machine (but this is another problem...) freddy77 wipe.diff Description: wipe.diff ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Ensuring data is written to disk
Jens Axboe wrote: > > > For SATA you always need at least one cache flush (you need one if you > > > have the FUA/Forced Unit Access write available, you need two if not). > > > > Well my question wasn't intended to be specific to ATA (sorry if that > > wasn't clear), but a general question about writing to disks on Linux. > > > > And I don't understand your answer. Are you saying that reiserfs on > > Linux (presumably 2.6) commits data (and file metadata) to disk > > platters before returning from fsync(), for all types of disk > > including PATA, SATA and SCSI? Or if not, is that a known property of > > PATA only, or PATA and SATA only? (And in all cases, presumably only > > "ordinary" controllers can be depended on, not RAID controllers or > > USB/Firewire bridges which ignore cache flushes for no good reason). > > blkdev_issue_flush() is brutal, but it works on SATA/PATA/SCSI. So yes, > it should eb reliable. Ah, thanks. I've looked at that bit of reiserfs, xfs and ext3 now. It looks like adding a single call to blkdev_issue_flush() at the end of ext3_sync_file() would do the trick. I'm surprised that one-line patch isn't in there already. Of course that doesn't help with writing an application to reliably commit on existing systems. > > > > 2. Do you know if ext3 (in ordered mode) w/barriers on Linux does it > > > > too, > > > >for in-place writes which don't modify the inode and therefore don't > > > >have a journal entry? > > > > > > I don't think that it does, however it may have changed. A quick grep > > > would seem to indicate that it has not changed. > > > > Ew. What do databases do to be reliable then? Or aren't they, on Linux? > > They probably run on better storage than commodity SATA drives with > write back caching enabled. To my knowledge, Linux is one of the only OS > that even attempts to fix this. I would imagine most of the MySQL databases backing small web sites run on commodity PATA or SATA drives, and that most people have assumed fsync() to be good enough for database commits in the absence of hardware failure, or when one disk goes down in a RAID. Time to correct those misassumption! > > > > On Darwin, fsync() does not issue CACHEFLUSH to the drive. Instead, > > > > it has an fcntl F_FULLSYNC which does that, which is documented in > > > > Darwin's fsync() page as working with all Darwin's filesystems, > > > > provided the hardware honours CACHEFLUSH or the equivalent. > > > > > > That seems somewhat strange to me, I'd much rather be able to say that > > > fsync() itself is safe. An added fcntl hack doesn't really help the > > > applications that already rely on the correct behaviour. > > > > According to the Darwin fsync(2) man page, it claims Darwin is the > > only OS which has a facility to commit the data to disk platters. > > (And it claims to do this with IDE, SCSI and FibreChannel. With > > journalling filesystems, it requests the journal to do the commit but > > the cache flush still ultimately reaches the disk. Sounds like a good > > implementation to me). > > The implementation may be nice, but it's the idea that is appalling to > me. But it sounds like the Darwin man page is out of date, or at least > untrue. > > > SQLite (a nice open source database) will use F_FULLSYNC on Darwin to > > do this, and it appears to add a large performance penalty relative to > > using fsync() alone. People noticed and wondered why. > > Disk cache flushes are nasty, they stall everything. But it's still > typically faster than disabling write back caching, so... I agree that it's nasty. But then, the fsync() interface is rather sub-optimal. E.g. something like sendmail which writes a new file needs to fsync() on the file _and_ its parent directory. You don't want two disk flushes then, just one after both fsync() calls have completed. Similarly if you're doing anything where you want to commit data to more than one file. An fsync_multi() interface would be more efficient. > > Other OSes show similar performance as Darwin with fsync() only. > > > > So it looks like the man page is probably accurate: other OSes, > > particularly including Linux, don't commit the data reliably to disk > > platters when using fsync(). > > How did you reach that conclusion? >From seeing the reported timings for SQLite on Linux and Darwin with/without F_FULLSYNC. The Linux timings were similar to Darwin without F_FULLSYNC. Others and myself assumed the timings are probably I/O bound, and reflect the transactions going to disk. But it could be Darwin being slower :-) > reiser certainly does it if you have barriers enabled (which you > need anyways to be safe with write back caching), and with a little > investigation we can perhaps conclude that XFS is safe as well. Yes, reiser and XFS look quite convincing. Although I notice the blkdev_issue_flush is conditional in both, and the condition is non-trivial. I'll assume the authors thought specifically about t
Re: [Qemu-devel] Interesting QEMU + OpenVPN
On Tuesday 01 August 2006 4:29 pm, Jonathan Kalbfeld wrote: > I have an instance of NetBSD 3.0.1 that runs inside of QEMU emulating an > i386. > > On the parent system, whether it is Windows, Linux, Solaris, or *BSD, > you can run an OpenVPN instance and set up a tunnel. > > On the guest system, you can then run OpenVPN and connect to the other > end of the tunnel. > > Voila! Now, from the parent system, you can connect directly to your > QEMU instance by using the tunnel. > > I set this up on my Sun Blade and am using it to test protocols. My > next task will be setting up a Virtual Ethernet Bridge between an > emulated i386 on QEMU here in LA and a real-live NetBSD brick at my > parents' home in Detroit. > > Interesting stuff! > > jonathan I have used OpenVPN in this scenario and it works exceptionally well, especially since you can bridge the adapters on the host and transparently connect the guest to your internal LAN. Maybe one day qemu will have builtin OpenVPN support so it won't have to be installed on the guest? -Joseph ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Interesting QEMU + OpenVPN
> I have used OpenVPN in this scenario and it works exceptionally well, > especially since you can bridge the adapters on the host and transparently > connect the guest to your internal LAN. Maybe one day qemu will have > builtin OpenVPN support so it won't have to be installed on the guest? You can already bridge the host and gues using the existing networking options (and/or VDE - http://vde.sf.net), without the encryption overhead and without needing any special setup on the guest. If you actually need the encryption then IMHO that's best left to dedicated packages like OpenVPN. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Ensuring data is written to disk
Just to throw in my two cents, I notice that on the namesys website, they claim reiser4 is completely safe in the event of a power failure, while reiserfs 3 still requires some recovery. Apparently in reiser4 they somehow design writes to happen in sequences that create atomic events. So the whole change is there, or none of it. I am not sure how this is accomplished given the state of disk caching... Perhaps that is why they don't consider reiser4 ready for prime time use. BillOn 8/2/06, Jamie Lokier <[EMAIL PROTECTED]> wrote: Jens Axboe wrote:> > > For SATA you always need at least one cache flush (you need one if you> > > have the FUA/Forced Unit Access write available, you need two if not).> >> > Well my question wasn't intended to be specific to ATA (sorry if that > > wasn't clear), but a general question about writing to disks on Linux.> >> > And I don't understand your answer. Are you saying that reiserfs on> > Linux (presumably 2.6) commits data (and file metadata) to disk > > platters before returning from fsync(), for all types of disk> > including PATA, SATA and SCSI? Or if not, is that a known property of> > PATA only, or PATA and SATA only? (And in all cases, presumably only > > "ordinary" controllers can be depended on, not RAID controllers or> > USB/Firewire bridges which ignore cache flushes for no good reason).>> blkdev_issue_flush() is brutal, but it works on SATA/PATA/SCSI. So yes, > it should eb reliable.Ah, thanks. I've looked at that bit of reiserfs, xfs and ext3 now.It looks like adding a single call to blkdev_issue_flush() at the endof ext3_sync_file() would do the trick. I'm surprised that one-line patch isn't in there already.Of course that doesn't help with writing an application to reliablycommit on existing systems.> > > > 2. Do you know if ext3 (in ordered mode) w/barriers on Linux does it too, > > > >for in-place writes which don't modify the inode and therefore don't> > > >have a journal entry?> > >> > > I don't think that it does, however it may have changed. A quick grep > > > would seem to indicate that it has not changed.> >> > Ew. What do databases do to be reliable then? Or aren't they, on Linux?>> They probably run on better storage than commodity SATA drives with > write back caching enabled. To my knowledge, Linux is one of the only OS> that even attempts to fix this.I would imagine most of the MySQL databases backing small web sitesrun on commodity PATA or SATA drives, and that most people have assumed fsync() to be good enough for database commits in the absenceof hardware failure, or when one disk goes down in a RAID. Time tocorrect those misassumption!> > > > On Darwin, fsync() does not issue CACHEFLUSH to the drive. Instead, > > > > it has an fcntl F_FULLSYNC which does that, which is documented in> > > > Darwin's fsync() page as working with all Darwin's filesystems,> > > > provided the hardware honours CACHEFLUSH or the equivalent. > > >> > > That seems somewhat strange to me, I'd much rather be able to say that> > > fsync() itself is safe. An added fcntl hack doesn't really help the> > > applications that already rely on the correct behaviour. > >> > According to the Darwin fsync(2) man page, it claims Darwin is the> > only OS which has a facility to commit the data to disk platters.> > (And it claims to do this with IDE, SCSI and FibreChannel. With > > journalling filesystems, it requests the journal to do the commit but> > the cache flush still ultimately reaches the disk. Sounds like a good> > implementation to me).>> The implementation may be nice, but it's the idea that is appalling to > me. But it sounds like the Darwin man page is out of date, or at least> untrue.>> > SQLite (a nice open source database) will use F_FULLSYNC on Darwin to> > do this, and it appears to add a large performance penalty relative to > > using fsync() alone. People noticed and wondered why.>> Disk cache flushes are nasty, they stall everything. But it's still> typically faster than disabling write back caching, so... I agree that it's nasty. But then, the fsync() interface is rathersub-optimal. E.g. something like sendmail which writes a new fileneeds to fsync() on the file _and_ its parent directory. You don'twant two disk flushes then, just one after both fsync() calls have completed. Similarly if you're doing anything where you want tocommit data to more than one file. An fsync_multi() interface wouldbe more efficient.> > Other OSes show similar performance as Darwin with fsync() only. > >> > So it looks like the man page is probably accurate: other OSes,> > particularly including Linux, don't commit the data reliably to disk> > platters when using fsync().> > How did you reach that conclusion?>From seeing the reported timings for SQLite on Linux and Darwinwith/without F_FULLSYNC. The Linux timings were similar to Darwinwithout F_FULLSYNC. Others and myself assumed the timings are probably I/O bound, and reflect the transactions going to disk
[Qemu-devel] Using QEMU on a XP Pro desktop, and then using remote desktop - mouse weirdness
Hello, I occasionally will run QEMU virtual machines on my work computer which is running windows XP (the virtual machines run a variety of OS's). When I am at home, I'll often "Remote Desktop" (I'll shorten it to RD from here on) into my work computer. For those who are not familiar with RD, it basically lets you use the remote computer (mostly) as if you're sitting directly in front of it. Similar to VNC or X-windows in concept. When I try to use the mouse when I'm RD'd into my work computer, the mouse cursor doesn't seem to move within the QEMU window until the "real" mouse position crosses the horizontal or vertical middle of the screen. Depending on the axis that is cross, the cursor will move that direction extremely rapidly until it stops at the edge of the screen. Due to the lack of control it is impossible to click on anything except for the the edge of the window. I can only assume it's something with the way mouse coordinates are translated via remote desktop versus natively. The mouse works just fine when I'm natively at my work console. The newly added USB Tablet mode with it's absolute coordinates (I think that is what it added) didn't seem to make a difference. I have a feeling this is essentially an SDL problem, but I thought I'd bounce it off the gurus here for ideas. Suggestions? Or any takers to look into it? :) This is beyond my expertise or what I have time to investigate. I'm completely unfamiliar with the QEMU code, SDL code, and interpreting mouse coordinates programmatically, so it'd take me weeks (months) to try to track it down and devise a patch. Thank you for your time.. -- James Funny quotes: "There are 10 types of people in the world. Those who understand binary, and those who don't." -- Unknown "A computer once beat me at chess, but it was no match for me at kick boxing." -- Emo Philips ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Wipe patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brad Campbell wrote: > While I'm here does anyone know of a simple program, either dos or linux > based for wiping unused space on fat filesystems? The only ones I've > found so far have been windows based. For DOS and FAT16, I'm using Wipem. See http://short.stop.home.att.net/freesoft/disk2.htm#wipers I'm intersted too in such tools to write zeros to the free space. Either Linux or DOS (FAT32). Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0OGskyKr2gmercERAreaAKCY7SdMwQ3bVGSp2PW/smmXTsA/wgCfepwE hy6rYccDSQT5B4O9Cy+MOPY= =1T4Y -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Win32 MinGW build with current CVS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello It seems that the aio support broke my MinGW build batch under Win32. Is it suposed to work on WIN32 ? Any ideas ? Andreas gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. -I.. - -I/D/DEV/QEMU/qemu/target-i386 -I/D/DEV/QEMU/qemu -D_GNU_SOURCE - -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/D/DEV/QEMU/qemu/fpu - -DHAS_AUDIO -I/D/DEV/QEMU/qemu/slirp -c -o block-raw.o /D/DEV/QEMU/qemu/block-raw.c d:/DEV/QEMU/qemu/block-raw.c: In function `raw_open': d:/DEV/QEMU/qemu/block-raw.c:573: `BDRV_O_CREATE' undeclared (first use in this function) d:/DEV/QEMU/qemu/block-raw.c:573: (Each undeclared identifier is reported only once d:/DEV/QEMU/qemu/block-raw.c:573: for each function it appears in.) d:/DEV/QEMU/qemu/block-raw.c: In function `raw_aio_new': d:/DEV/QEMU/qemu/block-raw.c:635: structure has no member named `hevent' d:/DEV/QEMU/qemu/block-raw.c:636: structure has no member named `hevent' d:/DEV/QEMU/qemu/block-raw.c: In function `raw_aio_cb': d:/DEV/QEMU/qemu/block-raw.c:643: `acb1' undeclared (first use in this function) d:/DEV/QEMU/qemu/block-raw.c:648: `s' undeclared (first use in this function) d:/DEV/QEMU/qemu/block-raw.c: In function `raw_aio_read': d:/DEV/QEMU/qemu/block-raw.c:662: warning: unused variable `ret_count' d:/DEV/QEMU/qemu/block-raw.c: In function `raw_aio_write': d:/DEV/QEMU/qemu/block-raw.c:685: warning: unused variable `ret_count' d:/DEV/QEMU/qemu/block-raw.c: In function `raw_truncate': d:/DEV/QEMU/qemu/block-raw.c:737: `length' undeclared (first use in this function) d:/DEV/QEMU/qemu/vl.h: At top level: d:/DEV/QEMU/qemu/block-raw.c:627: warning: `raw_aio_new' defined but not used d:/DEV/QEMU/qemu/block-raw.c:658: warning: `raw_aio_read' defined but not used d:/DEV/QEMU/qemu/block-raw.c:681: warning: `raw_aio_write' defined but not used d:/DEV/QEMU/qemu/block-raw.c:714: warning: `raw_aio_delete' defined but not used make: *** [block-raw.o] Error 1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0OnykyKr2gmercERAq3gAJ9hX0tp0/uqCCUrUy1ctCyVih71twCgjRi+ ys2Km+sxRKMZSTPRux+yCi8= =DDwp -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Win32 MinGW build with current CVS
On Wed, 02 Aug 2006 20:07:46 +0200, Andreas Bollhalder <[EMAIL PROTECTED]> wrote: Hello It seems that the aio support broke my MinGW build batch under Win32. Is it suposed to work on WIN32 ? Any ideas ? Andreas ... Hi! "Kernel Asynchronous I/O (AIO) Support for Linux Overview AIO enables even a single application thread to overlap I/O operations with other processing, by providing an interface for submitting one or more I/O requests in one system call (io_submit()) without waiting for completion, and a separate interface (io_getevents()) to reap completed I/O operations associated with a given completion group. Support for kernel AIO has been included in the 2.6 Linux kernel." source: http://lse.sourceforge.net/io/aio.html So, I don't think so. But please correct me, if I'm wrong. Nyos --- Delay not, Caesar. Read it instantly. -- Shakespeare, "Julius Caesar" 3,1 Here is a letter, read it at your leisure. -- Shakespeare, "Merchant of Venice" 5,1 [Quoted in "VMS Internals and Data Structures", V4.4, when referring to I/O system services.] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] sparc emulation tcx_update_display fix
Hi!Noticed that integer promotion precludes tcx display emulator from resetting VGA_DIRTY_FLAG on pages it scanned, patch attached.Before this change, ~75% host cpu is busy with drawing display lines, now it is ~1% only.
Index: hw/tcx.c
===
RCS file: /cvsroot/qemu/qemu/hw/tcx.c,v
retrieving revision 1.7
diff -u -r1.7 tcx.c
--- hw/tcx.c 9 Apr 2006 01:06:34 - 1.7
+++ hw/tcx.c 2 Aug 2006 20:36:04 -
@@ -86,8 +86,8 @@
static void tcx_update_display(void *opaque)
{
TCXState *ts = opaque;
-uint32_t page;
-int y, page_min, page_max, y_start, dd, ds;
+unsigned long page, page_min, page_max;
+int y, y_start, dd, ds;
uint8_t *d, *s;
void (*f)(TCXState *s1, uint8_t *d, const uint8_t *s, int width);
@@ -96,7 +96,7 @@
page = ts->vram_offset;
y_start = -1;
page_min = 0x7fff;
-page_max = -1;
+page_max = 0;
d = ts->ds->data;
s = ts->vram;
dd = ts->ds->linesize;
@@ -154,7 +154,7 @@
ts->width, y - y_start);
}
/* reset modified pages */
-if (page_max != -1) {
+if (page_max > 0) {
cpu_physical_memory_reset_dirty(page_min, page_max + TARGET_PAGE_SIZE,
VGA_DIRTY_FLAG);
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to Simulate hardware that counts scanlines?
That's great news, thanks for letting us know. Steve The next release of QEMU is likely to have cycle exact emulation and delivery of interrupts in the middle of a basic block. Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] How to reply when receiving digest mode
I must be blind and stupid, but I don't see any obvious easy way to reply to a message when I get the list via dialy batched digest mode. Replying is a pain, as I have to do it manually by surfing to the mail archives, find the thread I want to reply, and cut & paste the text etc.. Is there any easier way? I'd prefer to keep digest mode if possible, but replying is becomming annoying. I was thinking that each digest message would have some kind of reply link, but if it does, I don't see it.. Thanks -Steve ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Run Real Time Guest OS?
BRAD YOU ROCK!! LOL.. It works!!! I'm not sure what you meant by "you would most certainly want a HZ value of 1000 to try this", but I simply changed the #define to 4096 as you suggested, put it on my fastest machine, and it works perfectly! I didn't even get the message saying to echo > 1024 (or in this case 4096), it just worked!! DUDE! I owe you a beer! THANK YOU!! :) So why when I googled - did I see everywhere it talk about linux having a 1ms max resolution for timers? I can dig up some links if you need me to. This is confusing and what led me down the road to thinking I needed RTLinux or some other thing. I"m so thrilled not to have to go there! Perhaps linux can't guarantee a reliable and consistent frequency for the timer at speeds above 1ms, and any one needing 100% reliable timing would need an RT OS? Sure seemed pretty rock solid for me when I ran it, though it's a peppy machine. Anyway, your reply really made my day, no, heck it made my last 2 weeks, since my project is now nearing completion and is running perfectly so far thanks to this tiny change! It's funny, I had thought to try it myself a few days ago, but was discouraged by what I read on google, and never bothered. DOH! -Steve Not at all.. for a single qemu instance on linux it tries to use the PIT in the rtc, and I've seen this run upto 8192hz. Why not crank it up in the qemu source t0 4096 and see what happens. It's not going to hurt anything in any case. You would most certainly want a HZ value of 1000 to try this. Brad ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to Simulate hardware that counts scanlines?
Thanks malc- Turns out I didn't need it after all. Once I pumped up my RTC Frequency to 4096 from 1024 (thanks Brad), my 'fake' scanline counting code seemed to satisfy the machine and all looks perfect. Thanks for the help anyway, it was much appreciated, and may serve useful for future projects. Regards- Steve From: malc <[EMAIL PROTECTED]> To: Steve Ellenoff <[EMAIL PROTECTED]> Subject: Re: [Qemu-devel] How to Simulate hardware that counts scanlines? Date: Tue, 1 Aug 2006 04:16:32 +0400 (MSD) On Mon, 31 Jul 2006, Steve Ellenoff wrote: You misunderstand, I have no control over the running program. I didn't write it, I don't have source code, and I surely wouldn't have used a polling mechanism for determining the vblank as you suggested. My problem is that I wish to run this program through qemu. I've made a bunch of hardware specific additions to qemu to emulate the specific hardware this program runs on. I'm just not sure the best way to simulate the scanline counting the hardware does. Seems nobody here has any ideas either, which is kind of hard to believe. I don't know if this would work, but one idea I had was to divide up the gui timer into 260 slices (that's the # of scanlines the hardware expects), and simply update the hardware register that counts the scanlines this way. Does anyone thing that's the way to go, or if there's a better way? I don't know wether this is applicable or not, but it might help: http://www.boblycat.org/~malc/code/patches/qemu/5c_rqemu.patch.gz Is the patch that does something that sounds a bit like what you want. Basically this tries to provide a bit better h/v retrace polling support than what qemu orignally does (needed for some old DOS applications) Each time guest reads the VGA register that contains h/v retrace bits the virtual time is calculated and that gives some indication where the beam might be at the current point in time, with a bit of tweaking this can report current scanline and whatnot too. -- mailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu block-raw.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/08/02 22:02:08 Modified files: . : block-raw.c Log message: some compilation fixes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw.c?cvsroot=qemu&r1=1.1&r2=1.2 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Fwd: sparc emulation tcx_update_display fix
Resending, sorry if this is a duplicate-- Forwarded message --From: Igor KovalenkoDate: Aug 3, 2006 12:48 AMSubject: sparc emulation tcx_update_display fix
To: qemu-devel@nongnu.orgHi!Noticed that integer promotion precludes tcx display emulator from resetting VGA_DIRTY_FLAG on pages it scanned, patch attached.
Before this change, ~75% host cpu is busy with drawing display lines, now it is ~1% only.
Index: hw/tcx.c
===
RCS file: /cvsroot/qemu/qemu/hw/tcx.c,v
retrieving revision 1.7
diff -u -r1.7 tcx.c
--- hw/tcx.c 9 Apr 2006 01:06:34 - 1.7
+++ hw/tcx.c 2 Aug 2006 20:36:04 -
@@ -86,8 +86,8 @@
static void tcx_update_display(void *opaque)
{
TCXState *ts = opaque;
-uint32_t page;
-int y, page_min, page_max, y_start, dd, ds;
+unsigned long page, page_min, page_max;
+int y, y_start, dd, ds;
uint8_t *d, *s;
void (*f)(TCXState *s1, uint8_t *d, const uint8_t *s, int width);
@@ -96,7 +96,7 @@
page = ts->vram_offset;
y_start = -1;
page_min = 0x7fff;
-page_max = -1;
+page_max = 0;
d = ts->ds->data;
s = ts->vram;
dd = ts->ds->linesize;
@@ -154,7 +154,7 @@
ts->width, y - y_start);
}
/* reset modified pages */
-if (page_max != -1) {
+if (page_max > 0) {
cpu_physical_memory_reset_dirty(page_min, page_max + TARGET_PAGE_SIZE,
VGA_DIRTY_FLAG);
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw tcx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/08/02 22:19:33 Modified files: hw : tcx.c Log message: fixed refresh logic (initial patch by Igor Kovalenko) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/tcx.c?cvsroot=qemu&r1=1.7&r2=1.8 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to reply when receiving digest mode
On Wed, 02 Aug 2006 21:31:02 + "Steve Ellenoff" <[EMAIL PROTECTED]> wrote: > I must be blind and stupid, but I don't see any obvious easy way to > reply to a message when I get the list via dialy batched digest mode. > Replying is a pain, as I have to do it manually by surfing to the > mail archives, find the thread I want to reply, and cut & paste the > text etc.. Is there any easier way? I'd prefer to keep digest mode if > possible, but replying is becomming annoying. > I was thinking that each digest message would have some kind of reply > link, but if it does, I don't see it.. If you choose MIME digests (where every message is an attachment), and your email client is smart enough, you can reply to the individual attachments. I couldn't say whether hotmail is smart enough, however. -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: AltGr keystrokes
2006/8/2, Anthony Liguori <[EMAIL PROTECTED]>: You're right, I'll submit a patch to fix that. Let me know if it helps. Well, it indeed helps to some extent, but it's not enough. Tracking down the problem I've found out that modifiers after scancodes in keymap files are completely ignored in function parse_keyboard_layout (keymaps.c). In "es" keymap we find: quotedbl 0x03 shift at 0x03 altgr Which means " ==> Shift + 2 @ ==> AltGr + 2 Logging TightVNC client messages: [ PRESS SHIFT ] VNC msg: DOWN 0xFFE1 --> OS receives keycode: 0x2A [ PRESS 2 ] VNC msg: DOWN 0x22 --> OS receives keycode: 0x03 [ RELEASE 2 ] VNC msg: UP 0x22 --> OS receives keycode: 0x03 [ RELEASE SHIFT ] VNC msg: UP 0xFFE1 --> OS receives keycode: 0x2A This works correctly and double quote is printed, but... [ PRESS ALTGR ] VNC msg: DOWN 0xFFE3 --> OS receives keycode: 0x1D VNC msg: DOWN 0xFFEA --> OS receives keycode: 0x38 [ PRESS 2 ] VNC msg: UP 0xFFE3 --> OS receives keycode: 0x1D VNC msg: UP 0xFFEA --> OS receives keycode: 0x38 VNC msg: DOWN 0x40 --> OS receives keycode: 0x03 VNC msg: DOWN 0xFFEA --> OS receives keycode: 0x38 VNC msg: UP 0xFFE3 --> OS receives keycode: 0x1D VNC msg: UP 0xFFE3 --> OS receives keycode: 0x1D VNC msg: UP 0xFFEA --> OS receives keycode: 0x38 VNC msg: UP 0x40 --> OS receives keycode: 0x03 VNC msg: DOWN 0xFFEA --> OS receives keycode: 0x38 VNC msg: UP 0xFFE3 --> OS receives keycode: 0x1D VNC msg: UP 0xFFE3 --> OS receives keycode: 0x1D VNC msg: UP 0xFFEA --> OS receives keycode: 0x38 ... doesn't work at all. As you can see, VNC client sends messages to release AltGr modifier before sending 0x40 symbol ( @ ). It relies on the server to know how to get it. As the OS receives a bare 0x03 keycode, the resulting character is 2. Qemu should send to the OS the AltGr keydown event before the 0x03 scancode, as the keymap says. Double quote case shouldn't be affected by the extra Shift keydown event. Regards, Eduardo Felipe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Fwd: sparc emulation tcx_update_display fix
Has anyone successfully gotten qemu-system-sparc to run on Solaris 10/sparc? It keeps segfaulting before anything meaningful. jonathan On 8/2/06, Igor Kovalenko <[EMAIL PROTECTED]> wrote: Resending, sorry if this is a duplicate -- Forwarded message -- From: Igor Kovalenko Date: Aug 3, 2006 12:48 AM Subject: sparc emulation tcx_update_display fix To: qemu-devel@nongnu.org Hi! Noticed that integer promotion precludes tcx display emulator from resetting VGA_DIRTY_FLAG on pages it scanned, patch attached. Before this change, ~75% host cpu is busy with drawing display lines, now it is ~1% only. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- -- Jonathan Kalbfeld +1 323 620 6682 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: How to reply when receiving digest mode
You could pick up a newsreader and subscribe to gmane.comp.emulators.qemu on news.gmane.org. I'm responding to this note right now through gmane actually... Regards, Anthony Liguori On Wed, 02 Aug 2006 21:31:02 +, Steve Ellenoff wrote: > I must be blind and stupid, but I don't see any obvious easy way to reply > to a message when I get the list via dialy batched digest mode. Replying > is a pain, as I have to do it manually by surfing to the mail archives, > find the thread I want to reply, and cut & paste the text etc.. Is there > any easier way? I'd prefer to keep digest mode if possible, but replying > is becomming annoying. > I was thinking that each digest message would have some kind of reply > link, but if it does, I don't see it.. > > Thanks > -Steve ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re[2]: [Qemu-devel] State of TI OMAP board support?
Hello Andrzej, Sunday, July 30, 2006, 4:29:41 PM, you wrote: > Hi, > On 30/07/06, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: >> Hello qemu-devel, >> >> I wonder, what's the state of TI OMAP patch, previously announced on >> the list by Andrzej Zaborowski >> http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00125.html ? >> Is it considered for inclusion in the mainline? If not, what precludes >> that? > I made some progress on the OMAP 310 emulation but I probably won't > finish it till I absolutely need it (which might be soon). I think I > will consider it finished when I can run PalmOS 5.0 on it. Linux works > absolutely fine, but PalmOS boots only halfway through and gets stuck > in some loop (probably not the OMAP emulation fault, probably one of > the peripheral chips, which are also emulated). Running a > closed-source OS is a real stress-test for an emulator. Yes, I may say that the job you've already done is very impressive, and aims you have are even more ambitious. If you do PalmOS, WinCE will be next ;-). > I don't think it is considered for inclusion. Before it is merged I > would like to separate the generic OMAP code from board-related code > (the board I emulate is the Palm Tunsgten|E handheld), but I imagine > the QEMU maintainers won't like the way code is formatted and probably > many other things, hard to say. I really hoped to get response from QEMU author/ARM emulation maintainer regarding these points. Paul, any comments? Would you be interested to add more CPUs/boards? Any suggestion regarding this? Maybe if it is expected that there may be many implementation and they won't fit into core distribution, to provide API for plugin development? > If you want to emulate a different OMAP processor you'll probably want > to add the emulation of the DSP part, which 310 doesn't have and it > may a whole lot of additional work. Actually, I'm also working on porting a PDA to run Linux (iPaq 4150/XScale). So far I don't have strong need to run kernel compiled specifically for that device in QEMU, though SD support you implemented seems like very good addition for emulation of any PDA device. Anyway, I'm currently using Integrator/CP kernel from here: http://www.o-hand.com/~richard/qemu.html , which boots h4000 userland (Familiar Linux GPE) just fine. Well, that GPE image doesn't have suport for mouse, and QEMU cannot emulate touchscreen. So, first thing I'd be interested from your patch is that "absolute mouse" support. Its status is also not clear - googling gives lots of references, and over good period of time, but it seems that patch is still not in the mainline? Well, I guess I need to look closer at you patch and try do my builds based on it, before asking specific questions. > Also, my current tree is based on QEMU 0.8.0. Thanks, -- Paulmailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] State of TI OMAP board support?
> > I don't think it is considered for inclusion. Before it is merged I > > would like to separate the generic OMAP code from board-related code > > (the board I emulate is the Palm Tunsgten|E handheld), but I imagine > > the QEMU maintainers won't like the way code is formatted and probably > > many other things, hard to say. > > I really hoped to get response from QEMU author/ARM emulation maintainer > regarding these points. Paul, any comments? Would you be interested to > add more CPUs/boards? Any suggestion regarding this? Maybe if it is > expected that there may be many implementation and they won't fit into > core distribution, to provide API for plugin development? I've no objection to adding new boards/cpus[1]. However, unless I have some personal/commercial interest in that particular board it's up to the patch author(s) to get that support into a state where I'm happy merging it. If the original author thinks it needs cleanup before submission I'm inclined to believe them ;-) All the normal guidelines for patch submission apply. i.e. follow coding conventions, split changes into logically separate patches, don't mix cleanups with new features, etc. Paul [1] As discussed previously on this list there are unresolved legal issues with emulating ARMv6/v7 cpus, however that's not relevant in this case. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Win32 MinGW build with current CVS
Sent: Thursday, August 03, 2006 4:07 AM NyOS wrote: On Wed, 02 Aug 2006 20:07:46 +0200, Andreas Bollhalder <[EMAIL PROTECTED]> wrote: >> Hello >> >> It seems that the aio support broke my MinGW build batch under Win32. Is >> it suposed to work on WIN32 ? >> >> Any ideas ? >> >> Andreas ... >Support for kernel AIO has been included in the 2.6 Linux kernel." source: http://lse.sourceforge.net/io/aio.html >So, I don't think so. But please correct me, if I'm wrong. Asynchronous I/O is implemented by overlapped I/O for Win32 but it is not enabled. I tried to make the program. A patch attached fixs compile errors. I found some problems about it. GetFileSizeEx needs to define WINVER 0x0500. It means that Windows 98/Me host is not supported. If we try to support Win 98/Me host, it is necessary to change configure to use --enable-win9x and make another binary, etc. The first attempt to open a hard disk image with a drive letter always failed. After the second time is OK. Regards, Kazu qemu-20060803-aio.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] host_alarm for Win32
Hi, host_alarm_handler for Win32 is called 1000 times/sec but it doesn't always wake upWaitForMultipleObjects. The behavior is not the same as Linux host because signal always wake up select. A patch fixes it. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-host_alarm.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Using thread for serial for win32
Hi, I made a patch that uses a thread instead of polling for -serial option for Win32 . It improves a performance of a serial communication. A new option is introduced to connect two QEMUs by a named pipe. Usage: -serial pipe_client:com_1 -serial pipe_client: set the program a clinet mode and can connect to a server. com_1 is a name of the named pipe. A pair of -serial pipe: and -serial pipe_clinet: can connect QEMUs each other. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-serial-thread.patch I found another problem about using windbg. I will send a next post. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Workaround for windbg
Hi, My previous patch is not enough to use windbg. A rate of loop in main_loop in vl.c drops a lot. The rate does not drop for Fedora Core 4 guest but not good for RedHat 7.2 and Windows 2000. It is expected at least 1000 cycles/sec, but the rate drops to 130 cycles/sec while CPU load is high. It is the case while OS is booting. The rate is slow so that a communication through serial line is slow. I made a workaround for it and checked the data sending/receiving rate by it. The patch exits CPU loop in cpu_exec every 100 times and handle I/O of serial data. The rate of loop in main_loop is about 3 cycles/sec. Win2k booting time with windbg is much improved. The patch is not efficient so it can only be used for windbg. It seems that cpu_interrupt does not work while CPU load is high depending on a guest OS. Binary. http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-0.8.2-windbg.zip Patch. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-windbg.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re[2]: [Qemu-devel] State of TI OMAP board support?
On 03/08/06, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: Hello Andrzej, Sunday, July 30, 2006, 4:29:41 PM, you wrote: > Hi, > On 30/07/06, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: >> Hello qemu-devel, >> >> I wonder, what's the state of TI OMAP patch, previously announced on >> the list by Andrzej Zaborowski >> http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00125.html ? >> Is it considered for inclusion in the mainline? If not, what precludes >> that? > I made some progress on the OMAP 310 emulation but I probably won't > finish it till I absolutely need it (which might be soon). I think I > will consider it finished when I can run PalmOS 5.0 on it. Linux works > absolutely fine, but PalmOS boots only halfway through and gets stuck > in some loop (probably not the OMAP emulation fault, probably one of > the peripheral chips, which are also emulated). Running a > closed-source OS is a real stress-test for an emulator. Yes, I may say that the job you've already done is very impressive, and aims you have are even more ambitious. If you do PalmOS, WinCE will be next ;-). > I don't think it is considered for inclusion. Before it is merged I > would like to separate the generic OMAP code from board-related code > (the board I emulate is the Palm Tunsgten|E handheld), but I imagine > the QEMU maintainers won't like the way code is formatted and probably > many other things, hard to say. I really hoped to get response from QEMU author/ARM emulation maintainer regarding these points. Paul, any comments? Would you be interested to add more CPUs/boards? Any suggestion regarding this? Maybe if it is expected that there may be many implementation and they won't fit into core distribution, to provide API for plugin development? > If you want to emulate a different OMAP processor you'll probably want > to add the emulation of the DSP part, which 310 doesn't have and it > may a whole lot of additional work. Actually, I'm also working on porting a PDA to run Linux (iPaq 4150/XScale). So far I don't have strong need to run kernel compiled Ah, now I know, I've seen your commits on handhelds.org! There is a person working on PXA (I think 270) emulation in QEMU, but I think they're at implementing the CPU now and out of the other hardware there's only the serial port, but I don't know the details. I only remember the person's nick on IRC. specifically for that device in QEMU, though SD support you implemented seems like very good addition for emulation of any PDA device. Anyway, I'm currently using Integrator/CP kernel from here: http://www.o-hand.com/~richard/qemu.html , which boots h4000 userland (Familiar Linux GPE) just fine. Well, that GPE image doesn't have suport for mouse, and QEMU cannot emulate touchscreen. So, first thing I'd be interested from your patch is that "absolute mouse" support. The absolute mouse support in my patch was basically stolen from Anthony Liguori's early Wacom tablet patch. There are links to this patch in list archives, I'm not sure if it's integrated into QEMU yet, but there's a pointing device using absolute coordintates known as usb-tablet which is in the mainline already. I've been running GPE in QEMU as well, using mostly unmodified fs images from familiar.handhelds.org and SD emulation which you mentioned (IIRC I had to disable udev everytime). I took some screenshots which can be seen at http://zabor.org/balrog/palmte/ (filenames ending in "-emulator"). Its status is also not clear - googling gives lots of references, and over good period of time, but it seems that patch is still not in the mainline? Well, I guess I need to look closer at you patch and try do my builds based on it, before asking specific questions. > Also, my current tree is based on QEMU 0.8.0. Thanks, -- Paulmailto:[EMAIL PROTECTED] Good luck with your port. Regards, Andrzej -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] How to deliver a packet at a specified future time instant ?
Hi, I have a unique situation where I want the virtual machine running on top of Qemu to be given a network packet at a prespecified time instant. Elaborately, let us say the clock in WindowsXP VM running on top of Qemu is now at 03:00:43 hours. I have a packet which I want the VM to read at exactly 03:00:50 hours. I know this should be possible since the general idea of running a VM is to be able to control every aspect of its state. Any pointers into how and where things should be altered to accomplish this ? thanks Krishnan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
