Re : [Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P)
- Message d'origine De : Avi Kivity [EMAIL PROTECTED] À : qemu-devel@nongnu.org Cc : [EMAIL PROTECTED]; Jorge Lucángeli Obes [EMAIL PROTECTED] Envoyé le : Jeudi, 16 Août 2007, 7h23mn 16s Objet : Re: [Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P) Well, you can make it work with a header (you just have to pad it out to a fixed length or use a variable-offset format), but binfmt_misc might be a better choice. binfmt_misc is Linux specific. And while kvm is a Linux thing now, qemu isn't. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. Wouldnt be #! Linux specific too ? Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com
Re: Re : [Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P)
Sylvain Petreolle wrote: - Message d'origine De : Avi Kivity [EMAIL PROTECTED] À : qemu-devel@nongnu.org Cc : [EMAIL PROTECTED]; Jorge Lucángeli Obes [EMAIL PROTECTED] Envoyé le : Jeudi, 16 Août 2007, 7h23mn 16s Objet : Re: [Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P) Well, you can make it work with a header (you just have to pad it out to a fixed length or use a variable-offset format), but binfmt_misc might be a better choice. binfmt_misc is Linux specific. And while kvm is a Linux thing now, qemu isn't. Wouldnt be #! Linux specific too ? It's unix-specific, not Linux-specific. Windows users can change file associations to have qemu run .qcow files. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Re: [kvm-devel] [PATCH] Dynamic ticks
Luca,
One more comment on your patch: the logic in the following condition
does not fit the comment bellow it.
On Mon, Aug 13, 2007 at 10:37:41PM +0200, Luca Tettamanti wrote:
+if (use_dynamic_ticks() dynticks_create_timer()) {
+/* dynticks disabled or failed to create a timer, fallback
+ * to old code.
+ */
+[old code follows]
One should have
if (!use_dynamic_ticks() || dynticks_create_timer()) {
Instead.
Regards,
Dan.
Re: [Qemu-devel] merging kqemu into mainline kernel?
You don't need to compile kqemu into the kernel. When I install dkms-kqemu from freshrpms, I do NOT rebuild my kernel. I am fairly certain with Fedora's new policy for extras, there would not be much of a problem getting it added to Fedora. For that matter, it could probably get added into the new Enterprise Extra's repository as well. However, someone would need to volunteer to maintain the package. Bill On 8/4/07, dragoran [EMAIL PROTECTED] wrote: On 8/4/07, Ricardo Almeida [EMAIL PROTECTED] wrote: Hi, I'm just a user... Is it planned to submit kqemu to lkml for inclusion into the mainline kernel? Never seen anyone talking about this... if not why? Maybe because KVM was included (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 ) I know that if yes any idea when? is it possible to try to get it in 2.6.24 ? I don't know if Linus would accept it. As I said, KVM was included, although kqemu as the advantage of working in older hardware (without AMD-V or Intel equivalent virtualization instructions). Maybe if it was possible to make merge kqemu into KVM to take the best of the two... But I don't know anything about KVM nor kqemu code... thats the reason I (and many other users) want to see it merged. for ex. the fedora kernel maintainers don't want to add it until its part of the upstream kernel.
Re: [Qemu-devel] merging kqemu into mainline kernel?
Bill C. Riemers wrote: You don't need to compile kqemu into the kernel. When I install dkms-kqemu from freshrpms, I do NOT rebuild my kernel. I am fairly certain with Fedora's new policy for extras, there would not be much of a problem getting it added to Fedora. For that matter, it could probably get added into the new Enterprise Extra's repository as well. However, someone would need to volunteer to maintain the package. no thats not true fedora want to change the policy about out of tree modules the want to drop all kmod-* packages and only allow modules into the kernel rpm that are upstream or about to get merged upstream. anyway why has kqemu to be a out of tree module?
Re: [Qemu-devel] merging kqemu into mainline kernel?
On Thursday 16 August 2007, dragoran wrote: Bill C. Riemers wrote: You don't need to compile kqemu into the kernel. When I install dkms-kqemu from freshrpms, I do NOT rebuild my kernel. I am fairly certain with Fedora's new policy for extras, there would not be much of a problem getting it added to Fedora. For that matter, it could probably get added into the new Enterprise Extra's repository as well. However, someone would need to volunteer to maintain the package. no thats not true fedora want to change the policy about out of tree modules the want to drop all kmod-* packages and only allow modules into the kernel rpm that are upstream or about to get merged upstream. anyway why has kqemu to be a out of tree module? Mainly because the kernel already has one perfectly good virtualization interface. There's very little motivation to add another incompatible one, especially when the implementation is known to be fundamentally flawed, and probably insecure. If you really want to get it merged I suggest modifying kqemu to use the kvm interface, augmenting the kvm interface if necessary. Paul
Re: [Qemu-devel] merging kqemu into mainline kernel?
Are you referring to the API when you say interface, or the functionality itself? If the former that's a reasonable argument, but the latter is not valid since KVM requires a VT or AMD-V-capable processor, right? KQEMU does not, and therefore [today] works on a much larger installed base of hardware. Unless I am misunderstanding something? - Leo Reiter On 8/16/07, Paul Brook [EMAIL PROTECTED] wrote: On Thursday 16 August 2007, dragoran wrote: Bill C. Riemers wrote: You don't need to compile kqemu into the kernel. When I install dkms-kqemu from freshrpms, I do NOT rebuild my kernel. I am fairly certain with Fedora's new policy for extras, there would not be much of a problem getting it added to Fedora. For that matter, it could probably get added into the new Enterprise Extra's repository as well. However, someone would need to volunteer to maintain the package. no thats not true fedora want to change the policy about out of tree modules the want to drop all kmod-* packages and only allow modules into the kernel rpm that are upstream or about to get merged upstream. anyway why has kqemu to be a out of tree module? Mainly because the kernel already has one perfectly good virtualization interface. There's very little motivation to add another incompatible one, especially when the implementation is known to be fundamentally flawed, and probably insecure. If you really want to get it merged I suggest modifying kqemu to use the kvm interface, augmenting the kvm interface if necessary. Paul
Re: [Qemu-devel] merging kqemu into mainline kernel?
Mainly because the kernel already has one perfectly good virtualization interface. There's very little motivation to add another incompatible one, especially when the implementation is known to be fundamentally flawed, and probably insecure. If you really want to get it merged I suggest modifying kqemu to use the kvm interface, augmenting the kvm interface if necessary. Are you referring to the API when you say interface, or the functionality itself? If the former that's a reasonable argument, but the latter is not valid since KVM requires a VT or AMD-V-capable processor, right? KQEMU does not, and therefore [today] works on a much larger installed base of hardware. Yes, I mean the API. However in practice you'd probably want to try and share the implementation as well. In short it's likely to need rewriting before it's acceptable upstream. Paul P.S. Please don't top-post. Consider this your final warning.
Re: [Qemu-devel] merging kqemu into mainline kernel?
dragoran wrote: Bill C. Riemers wrote: You don't need to compile kqemu into the kernel. When I install dkms-kqemu from freshrpms, I do NOT rebuild my kernel. I am fairly certain with Fedora's new policy for extras, there would not be much of a problem getting it added to Fedora. For that matter, it could probably get added into the new Enterprise Extra's repository as well. However, someone would need to volunteer to maintain the package. no thats not true fedora want to change the policy about out of tree modules the want to drop all kmod-* packages and only allow modules into the kernel rpm that are upstream or about to get merged upstream. anyway why has kqemu to be a out of tree module? It looks like you are right. Apparently the plan is to move the acceptance of kernel modules to kernel maintainers. For the most part, they only want to accept very cleanly written modules that are likely to be integrated into the kernel. Since kqemu is viewed as a solution only for obsolete hardware, that is not likely to happen. It is a shame too, because kqemu provides a quality working solution for most of the hardware still in use today. Bill
Re: [Qemu-devel] merging kqemu into mainline kernel?
On Thursday, August 16, 2007, 15:49:14, Paul Brook wrote: Mainly because the kernel already has one perfectly good virtualization interface. Weren't both Xen and lguest recently merged to the (upcoming) 2.6.23 kernel? -- Jernej Simonèiè http://deepthought.ena.si/ If it looks easy, it's tough. If it looks tough, it's damn near impossible. -- Stockmayer's Theorem
Re: [Qemu-devel] [PATCH] Make ping work for -net user
On Thursday 16 August 2007, [EMAIL PROTECTED] wrote: This is a very simple proof-of-concept patch that fakes ICMP well enough for ping to work. Speaking of which... does ping work if qemu runs as root? As to the patch, it looks like it only works if you're testing whether you actually can ping or not. It wouldn't work with, for example, icmptx.
Re: [Qemu-devel] Re: [kvm-devel] Making qemu images executable (and store command line arguments in them =P)
On Thursday 16 August 2007, H. Peter Anvin wrote: Jorge Lucángeli Obes wrote: The '#!' trick works nice with scripts, but I don't see it playing very well with images. ¿Comments? ¿Pointers? Well, you can make it work with a header (you just have to pad it out to a fixed length or use a variable-offset format), but binfmt_misc might be a better choice. Can't hurt to support both, can it? ;)
Re: [Qemu-devel] merging kqemu into mainline kernel?
On Thu, Aug 16, 2007 at 05:01:42PM +0200, Jernej Simon?i? wrote: On Thursday, August 16, 2007, 15:49:14, Paul Brook wrote: Mainly because the kernel already has one perfectly good virtualization interface. Weren't both Xen and lguest recently merged to the (upcoming) 2.6.23 kernel? They're different to this scenario. Xen lguest are Host - Guest ABIs, and both ultimately use the common paravirt_ops API inside the kernel. kqemu kvm are Host Kernel - Host Userspace APIs, which are completely different, sharing no commonality in their APIs. kqemu stands very little chance getting merged unless it can share its userspace API model with KVM. This would have the added advantage that the QEMU binary would only need to talk one protocol to the kernel too, removing the need for the fork between plain QEMU KVM-ified QEMU. 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] merging kqemu into mainline kernel?
On Thursday 16 August 2007, Paul Brook wrote: If you really want to get it merged I suggest modifying kqemu to use the kvm interface, augmenting the kvm interface if necessary. This sounds like the way to go.
Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
Am 16.08.2007 um 01:52 schrieb Mark Williamson: I've missed some of the discussion, but wouldn't tar be an obvious choice? It can expand easily out to a directory hierarchy containing config file and multiple virtual disk files, there are standard tools that can manipulate it and standard libraries that can be used by Qemu in order to get at the contents. Only problem I see with this approach is that sparse file handling might get a bit strange (using real sparse files vs using tar's represesntation of sparse files vs compatibility with tars that don't support them!). Q uses the extension .qvm on an ordinary directory containing an XML configuration file and the image(s), so that double-clicking the directory opens the guest with Q. Can GNOME/KDE only do that for files so that an archive is necessary? Andreas
Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
Jorge Lucángeli Obes [EMAIL PROTECTED] wrote: I've been giving some thought to Anthony's idea: http://kvm.qumranet.com/kvmwiki/Specs/StoringCommandLineInImage However, maybe I'm just too much on vacations, but I don't seem to come up with a nice way of doing this. Everything keeps coming back to creating a new 'container' image format and then implementing block layer functions that only add the number of sectors occupied by the command-line to the read and write calls made by QEMU, and then just relay those calls to the image-specific functions. That doesn't sound very efficient. No, and it fundamentally breaks using a real disk with QEMU. The '#!' trick works nice with scripts, but I don't see it playing very well with images. ¿Comments? ¿Pointers? Personally, I'm not sure why we wouldn't just write out the command line data to a file tied to the primary image file, with some kind of time stamp to correlate the data from the command line and the last updated time of the primary image file. It's intuitive, and doesn't require a bucket of programming to make work. The down side is if qemu crashes, the time stamp between the parameter file and the image file may indicate the potential for difference, but this can just be a notice (just as snapshots used to do with the image files in 0.7.x) The only hard part here is when a real physical disk is used with QEMU since it's harder to make sure the name is valid. Thoughts? Ben
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
When I read Avi's TODO, I basically thought about getting rid of the long command lines I had to store in scripts. I wanted to write that command line once, and then forgetting about it, until I needed to change it. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing IMHO, it should be implemented at the shell level, not qemu level, like * is. The shell _does_ implement it: qemu `cat qemu.cfg` :-) If you want @ anyway, you can pick up the code from libiberty (or just build with libiberty). Segher
[Qemu-devel] Re: PATCH, RFC: Generic DMA framework
On 8/14/07, Blue Swirl [EMAIL PROTECTED] wrote: Would the framework need any changes to support other targets? Comments welcome. Replying to myself: Yes, changes may be needed. Some of the DMA controllers move the data outside CPU loop, but that does not make much difference. Background: I want to use the framework for at least devices that Sparc32/64 use. For Sparc32 the reason is that on Sun4c (Sparcstation 1, 2, IPX etc.) there is no IOMMU, but instead the CPU MMU is used for address translation. The DMA framework makes it possible to remove the IOMMU without changing the devices. On Sparc64 an IOMMU needs to be inserted between PCI devices and RAM without disturbing other targets. About the devices: Users of PC ISA DMA controller (SB16, FDC) pass the DMA position parameter to controller. I'm not sure this can be removed easily. Of course a real DMA controller does not get any position data from target. For Sparc32/64 I would not need to touch the PC ISA DMA devices, except maybe for FDC. On Sparc32, the FDC DMA is not even used. I have to think about this part. PCI DMA-like devices (eepro100, pcnet, rtl8139, ide) as well as PXA use cpu_physical_memory_rw to transfer data (eepro100 also uses ldl_phys, which looks very suspicious). These could be converted to generic DMA easily. OMAP DMA is strange, but fortunately I'm not interested in those devices.
Re: [Qemu-devel] adding support for above 2giga for qemu. ( include patchs )
On 8/14/07, Izik Eidus [EMAIL PROTECTED] wrote: anyway you have anyidea why it is working with kvm above 4giga and not with qemu??? can you look at how i did the mapping in qemu? Kqemu is not compatible with 2G, does it change anything if you run without kqemu? Also the assembly versions of softmmu access functions would need changing. To avoid that, you could try qemu on x86_64 or comment out the line for ASM_SOFTMMU in target-i386/op.c.
Re: [Qemu-devel] adding support for above 2giga for qemu. ( include patchs )
On Thu, 2007-08-16 at 21:41 +0300, Blue Swirl wrote: On 8/14/07, Izik Eidus [EMAIL PROTECTED] wrote: anyway you have anyidea why it is working with kvm above 4giga and not with qemu??? can you look at how i did the mapping in qemu? Kqemu is not compatible with 2G, does it change anything if you run without kqemu? i compiled it without Kqemu support. i dont work with qemu emulator, but was working with kvm + qemu tested on 32giga ram. Also the assembly versions of softmmu access functions would need changing. To avoid that, you could try qemu on x86_64 or comment out the line for ASM_SOFTMMU in target-i386/op.c. i will check this
Re: [Qemu-devel] merging kqemu into mainline kernel?
On 8/16/07, Paul Brook [EMAIL PROTECTED] wrote: Yes, I mean the API. However in practice you'd probably want to try and share the implementation as well. In short it's likely to need rewriting before it's acceptable upstream. Paul P.S. Please don't top-post. Consider this your final warning. blame it on gmail. this is the default behaviour. it's obviously not intended... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [Qemu-devel] merging kqemu into mainline kernel?
On 8/16/07, Christian MICHON [EMAIL PROTECTED] wrote: blame it on gmail. this is the default behaviour. it's obviously not intended... At the risk of drifting further off-topic, I'd just point out that you can press Ctrl-End in the Gmail message window before you type your reply. --Ed
[Qemu-devel] qemu vl.h hw/esp.c hw/pcnet.c hw/sparc32_dma.c ...
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/08/16 19:56:27 Modified files: . : vl.h hw : esp.c pcnet.c sparc32_dma.c sun4m.c Log message: Use qemu_irq for a reset signal between DMA and ESP/Lance CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.259r2=1.260 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/esp.c?cvsroot=qemur1=1.23r2=1.24 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pcnet.c?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sparc32_dma.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemur1=1.47r2=1.48
[Qemu-devel] qemu/hw sparc32_dma.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/08/16 19:57:27 Modified files: hw : sparc32_dma.c Log message: Remove old leftovers CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sparc32_dma.c?cvsroot=qemur1=1.7r2=1.8
Re: [Qemu-devel] Re: PATCH, RFC: Generic DMA framework
On Thu, 16 Aug 2007, Blue Swirl wrote: On 8/14/07, Blue Swirl [EMAIL PROTECTED] wrote: Would the framework need any changes to support other targets? Comments welcome. Replying to myself: Yes, changes may be needed. Some of the DMA controllers move the data outside CPU loop, but that does not make much difference. Background: I want to use the framework for at least devices that Sparc32/64 use. For Sparc32 the reason is that on Sun4c (Sparcstation 1, 2, IPX etc.) there is no IOMMU, but instead the CPU MMU is used for address translation. The DMA framework makes it possible to remove the IOMMU without changing the devices. On Sparc64 an IOMMU needs to be inserted between PCI devices and RAM without disturbing other targets. About the devices: Users of PC ISA DMA controller (SB16, FDC) pass the DMA position parameter to controller. I'm not sure this can be removed easily. Of course a real DMA controller does not get any position data from target. For Sparc32/64 I would not need to touch the PC ISA DMA devices, except maybe for FDC. On Sparc32, the FDC DMA is not even used. I have to think about this part. Very long time ago i changed the ISA DMA API to address some of the critique that Fabrice expressed, i can't remember offhand if that included removal of explicit position passing or not (the patch is on some off-line HDD so it's not easy to check whether it's in fact so) http://www.mail-archive.com/qemu-devel@nongnu.org/msg06594.html If needed i can try to locate the patch but the FDC problem still needs to be addressed by someone. PCI DMA-like devices (eepro100, pcnet, rtl8139, ide) as well as PXA use cpu_physical_memory_rw to transfer data (eepro100 also uses ldl_phys, which looks very suspicious). These could be converted to generic DMA easily. OMAP DMA is strange, but fortunately I'm not interested in those devices. -- vale
[Qemu-devel] sparc kqemu?
Is this on the horizon? Is there any interest in it? jonathan -- -- Jonathan Kalbfeld ThoughtWave Technologies LLC www.thoughtwave.com +1 323 620 6682
Re: [Qemu-devel] Making qemu images executable (and store command line arguments in them =P)
On Thu, Aug 16, 2007 at 01:05:41PM -0400, Ben Taylor wrote: Personally, I'm not sure why we wouldn't just write out the command line data to a file tied to the primary image file What about a compatible change to the file format: the last 1024 bytes are either undefined, or, if a certain marker is present, an executable commandline? (I was going to say one standard sector, then I thought of how quickly i18n filenames add up.) This is metadata, I have a feeling that if we think about it there will be quite a lot of other metadata we'd like to store with the image. with some kind of time stamp to correlate the data from the command line and the last updated time of the primary image file. If there have to be separate files I'd prefer a weak hash to timestamps to avoid the common problems with unexpected drift and no way to calculate which changed and why. -- Dan Shearer [EMAIL PROTECTED]
[Qemu-devel] [PATCH/RFC 2/4] Add -clock option.
Allow user to override the list of available alarm timers and their
priority. The format of the options is -clock clk1,clk2,...
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
---
qemu/vl.c | 90 --
1 files changed, 72 insertions(+), 18 deletions(-)
diff --git a/qemu/vl.c b/qemu/vl.c
index 33443ca..f0b4896 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -793,6 +793,71 @@ static struct qemu_alarm_timer alarm_timers[] = {
{NULL, }
};
+static void show_available_alarms()
+{
+int i;
+
+printf(Available alarm timers, in order of precedence:\n);
+for (i = 0; alarm_timers[i].name; i++)
+printf(%s\n, alarm_timers[i].name);
+}
+
+static void configure_alarms(char const *opt)
+{
+int i;
+int cur = 0;
+int count = (sizeof(alarm_timers) / sizeof(*alarm_timers)) - 1;
+char *arg;
+char *name;
+
+if (!strcmp(opt, help)) {
+show_available_alarms();
+exit(0);
+}
+
+arg = strdup(opt);
+
+/* Reorder the array */
+name = strtok(arg, ,);
+while (name) {
+struct qemu_alarm_timer tmp;
+
+for (i = 0; i count; i++) {
+if (!strcmp(alarm_timers[i].name, name))
+break;
+}
+
+if (i == count) {
+fprintf(stderr, Unknown clock %s\n, name);
+goto next;
+}
+
+if (i cur)
+/* Ignore */
+goto next;
+
+ /* Swap */
+tmp = alarm_timers[i];
+alarm_timers[i] = alarm_timers[cur];
+alarm_timers[cur] = tmp;
+
+cur++;
+next:
+name = strtok(NULL, ,);
+}
+
+free(arg);
+
+if (cur) {
+ /* Disable remaining timers */
+for (i = cur; i count; i++)
+alarm_timers[i].name = NULL;
+}
+
+/* debug */
+show_available_alarms();
+}
+
QEMUClock *rt_clock;
QEMUClock *vm_clock;
@@ -1035,8 +1100,6 @@ static void host_alarm_handler(int host_signum)
#define RTC_FREQ 1024
-static int use_rtc = 1;
-
static void enable_sigio_timer(int fd)
{
struct sigaction act;
@@ -1058,9 +1121,6 @@ static int rtc_start_timer(struct qemu_alarm_timer *t)
{
int rtc_fd;
-if (!use_rtc)
-return -1;
-
rtc_fd = open(/dev/rtc, O_RDONLY);
if (rtc_fd 0)
return -1;
@@ -6566,9 +6626,8 @@ void help(void)
-daemonize daemonize QEMU after initializing\n
#endif
-tdfinject timer interrupts that got lost\n
-#if defined(__linux__)
- -no-rtc don't use /dev/rtc for timer alarm (do use
gettimeofday)\n
-#endif
+ -clock force the use of the given methods for timer
alarm.\n
+ To see what timers are available use -clock help\n
-option-rom rom load a file, rom, into the option ROM space\n
\n
During emulation, the following keys are useful:\n
@@ -6658,9 +6717,7 @@ enum {
QEMU_OPTION_semihosting,
QEMU_OPTION_incoming,
QEMU_OPTION_tdf,
-#if defined(__linux__)
-QEMU_OPTION_no_rtc,
-#endif
+QEMU_OPTION_clock,
QEMU_OPTION_cpu_vendor,
};
@@ -6755,9 +6812,7 @@ const QEMUOption qemu_options[] = {
{ semihosting, 0, QEMU_OPTION_semihosting },
#endif
{ tdf, 0, QEMU_OPTION_tdf }, /* enable time drift fix */
-#if defined(__linux__)
-{ no-rtc, 0, QEMU_OPTION_no_rtc },
-#endif
+{ clock, HAS_ARG, QEMU_OPTION_clock },
{ cpu-vendor, HAS_ARG, QEMU_OPTION_cpu_vendor },
{ NULL },
};
@@ -7477,11 +7532,10 @@ int main(int argc, char **argv)
break;
case QEMU_OPTION_tdf:
time_drift_fix = 1;
-#if defined(__linux__)
- case QEMU_OPTION_no_rtc:
- use_rtc = 0;
break;
-#endif
+case QEMU_OPTION_clock:
+configure_alarms(optarg);
+break;
case QEMU_OPTION_cpu_vendor:
cpu_vendor_string = optarg;
break;
--
1.5.2.4
[Qemu-devel] [PATCH/RFC 0/4] Rework alarm timer infrastrucure.
Hello, in reply to this mail I will send a serie of 4 patches that cleans up and expands the alarm timer handling in QEMU. Patches apply to current kvm-userspace tree, but I think I can rebase it to QEMU svn if desired. Patch 1 is mostly a cleanup of the existing code; instead of having multiple #ifdefs to handle different timers scattered all over the code I've created a modular infrastructure where each timer type is self-contained and generic code is more readable. The resulting code is functionally equivalent to the old one. Patch 2 implements the -clock command line option proposed by Daniel Berrange and Avi Kivity. By default QEMU tries RTC and then falls back to unix timer; user can override the order of the timer through this options. Syntax is pretty simple: -clock timer1,timer2,etc. (QEMU will pick the first one that works). Patch 3 adds support for HPET under Linux (which is basically my old patch). As suggested HPET takes precedence over other timers, but of course this can be overridden. Patch 4 introduces dynticks timer source; patch is mostly based on the work Dan Kenigsberg. dynticks is now the default alarm timer.
[Qemu-devel] [PATCH/RFC 1/4] Rework alarm timer infrastrucure.
Make the alarm code modular, removing #ifdef from the generic code and
abstract a common interface for all the timer. The result is functionally
equivalent to the old code.
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
---
qemu/vl.c | 292 +--
1 files changed, 189 insertions(+), 103 deletions(-)
diff --git a/qemu/vl.c b/qemu/vl.c
index 5360ed7..33443ca 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -745,18 +745,58 @@ struct QEMUTimer {
struct QEMUTimer *next;
};
-QEMUClock *rt_clock;
-QEMUClock *vm_clock;
+struct qemu_alarm_timer {
+char const *name;
+
+int (*start)(struct qemu_alarm_timer *t);
+void (*stop)(struct qemu_alarm_timer *t);
+void *priv;
+};
+
+static struct qemu_alarm_timer *alarm_timer;
-static QEMUTimer *active_timers[2];
#ifdef _WIN32
-static MMRESULT timerID;
-static HANDLE host_alarm = NULL;
-static unsigned int period = 1;
+
+struct qemu_alarm_win32 {
+MMRESULT timerId;
+HANDLE host_alarm;
+unsigned int period;
+} alarm_win32_data = {0, NULL, -1};
+
+static int win32_start_timer(struct qemu_alarm_timer *t);
+static void win32_stop_timer(struct qemu_alarm_timer *t);
+
+#else
+
+static int unix_start_timer(struct qemu_alarm_timer *t);
+static void unix_stop_timer(struct qemu_alarm_timer *t);
+
+#ifdef __linux__
+
+static int rtc_start_timer(struct qemu_alarm_timer *t);
+static void rtc_stop_timer(struct qemu_alarm_timer *t);
+
+#endif
+
+#endif /* _WIN32 */
+
+static struct qemu_alarm_timer alarm_timers[] = {
+#ifdef __linux__
+/* RTC - if available - is preferred */
+{rtc, rtc_start_timer, rtc_stop_timer, NULL},
+#endif
+#ifndef _WIN32
+{unix, unix_start_timer, unix_stop_timer, NULL},
#else
-/* frequency of the times() clock tick */
-static int timer_freq;
+{win32, win32_start_timer, win32_stop_timer, alarm_win32_data},
#endif
+{NULL, }
+};
+
+QEMUClock *rt_clock;
+QEMUClock *vm_clock;
+
+static QEMUTimer *active_timers[2];
QEMUClock *qemu_new_clock(int type)
{
@@ -973,7 +1013,8 @@ static void host_alarm_handler(int host_signum)
qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock))) {
#ifdef _WIN32
-SetEvent(host_alarm);
+struct qemu_alarm_win32 *data = ((struct
qemu_alarm_timer*)dwUser)-priv;
+SetEvent(data-host_alarm);
#endif
CPUState *env = cpu_single_env;
if (env) {
@@ -995,10 +1036,31 @@ static void host_alarm_handler(int host_signum)
#define RTC_FREQ 1024
static int use_rtc = 1;
-static int rtc_fd;
-static int start_rtc_timer(void)
+static void enable_sigio_timer(int fd)
+{
+struct sigaction act;
+
+/* timer signal */
+sigfillset(act.sa_mask);
+act.sa_flags = 0;
+#if defined (TARGET_I386) defined(USE_CODE_COPY)
+act.sa_flags |= SA_ONSTACK;
+#endif
+act.sa_handler = host_alarm_handler;
+
+sigaction(SIGIO, act, NULL);
+fcntl(fd, F_SETFL, O_ASYNC);
+fcntl(fd, F_SETOWN, getpid());
+}
+
+static int rtc_start_timer(struct qemu_alarm_timer *t)
{
+int rtc_fd;
+
+if (!use_rtc)
+return -1;
+
rtc_fd = open(/dev/rtc, O_RDONLY);
if (rtc_fd 0)
return -1;
@@ -1009,121 +1071,145 @@ static int start_rtc_timer(void)
goto fail;
}
if (ioctl(rtc_fd, RTC_PIE_ON, 0) 0) {
-fail:
+fail:
close(rtc_fd);
return -1;
}
-pit_min_timer_count = PIT_FREQ / RTC_FREQ;
+
+enable_sigio_timer(rtc_fd);
+
+t-priv = (void *)rtc_fd;
+
return 0;
}
-#else
-
-static int start_rtc_timer(void)
+static void rtc_stop_timer(struct qemu_alarm_timer *t)
{
-return -1;
+int rtc_fd = (int)t-priv;
+
+close(rtc_fd);
}
#endif /* !defined(__linux__) */
-#endif /* !defined(_WIN32) */
+static int unix_start_timer(struct qemu_alarm_timer *t)
+{
+struct sigaction act;
+struct itimerval itv;
+int err;
-static void init_timer_alarm(void)
+/* timer signal */
+sigfillset(act.sa_mask);
+act.sa_flags = 0;
+#if defined(TARGET_I386) defined(USE_CODE_COPY)
+act.sa_flags |= SA_ONSTACK;
+#endif
+act.sa_handler = host_alarm_handler;
+
+sigaction(SIGALRM, act, NULL);
+
+itv.it_interval.tv_sec = 0;
+/* for i386 kernel 2.6 to get 1 ms */
+itv.it_interval.tv_usec = 999;
+itv.it_value.tv_sec = 0;
+itv.it_value.tv_usec = 10 * 1000;
+
+err = setitimer(ITIMER_REAL, itv, NULL);
+if (err)
+return -1;
+
+return 0;
+}
+
+static void unix_stop_timer(struct qemu_alarm_timer *t)
{
+struct itimerval itv;
+
+memset(itv, 0, sizeof(itv));
+setitimer(ITIMER_REAL, itv, NULL);
+}
+
+#endif /* !defined(_WIN32) */
+
#ifdef _WIN32
-{
-int count=0;
-TIMECAPS tc;
-
-ZeroMemory(tc, sizeof(TIMECAPS));
-timeGetDevCaps(tc, sizeof(TIMECAPS));
-if (period tc.wPeriodMin)
-period = tc.wPeriodMin;
-timeBeginPeriod(period);
-timerID =
[Qemu-devel] [PATCH/RFC 4/4] Add support for dynamic ticks.
If DYNAMIC_TICKS is defined qemu does not attepmt to generate SIGALRM at a
constant rate. Rather, the system timer is set to generate SIGALRM only
when it is needed. DYNAMIC_TICKS reduces the number of SIGALRMs sent to
idle dynamic-ticked guests.
Original patch from Dan Kenigsberg [EMAIL PROTECTED]
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
---
qemu/configure |5 ++
qemu/vl.c | 149 --
2 files changed, 148 insertions(+), 6 deletions(-)
diff --git a/qemu/configure b/qemu/configure
index 365b7fb..38373db 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -262,6 +262,8 @@ for opt do
;;
--enable-uname-release=*) uname_release=$optarg
;;
+ --disable-dynamic-ticks) dynamic_ticks=no
+ ;;
esac
done
@@ -788,6 +790,9 @@ echo TARGET_DIRS=$target_list $config_mak
if [ $build_docs = yes ] ; then
echo BUILD_DOCS=yes $config_mak
fi
+if test $dynamic_ticks != no ; then
+ echo #define DYNAMIC_TICKS 1 $config_h
+fi
# XXX: suppress that
if [ $bsd = yes ] ; then
diff --git a/qemu/vl.c b/qemu/vl.c
index 0373beb..096729d 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -748,12 +748,42 @@ struct QEMUTimer {
struct qemu_alarm_timer {
char const *name;
+unsigned int flags;
int (*start)(struct qemu_alarm_timer *t);
void (*stop)(struct qemu_alarm_timer *t);
+void (*rearm)(struct qemu_alarm_timer *t);
void *priv;
};
+#define ALARM_FLAG_DYNTICKS 0x1
+
+#ifdef DYNAMIC_TICKS
+
+static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
+{
+return t-flags ALARM_FLAG_DYNTICKS;
+}
+
+static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t) {
+if (!alarm_has_dynticks(t))
+return;
+
+t-rearm(t);
+}
+
+#else /* DYNAMIC_TICKS */
+
+static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
+{
+return 0;
+}
+
+static void qemu_rearm_alarm_timer(void) {
+}
+
+#endif /* DYNAMIC_TICKS */
+
static struct qemu_alarm_timer *alarm_timer;
#ifdef _WIN32
@@ -772,6 +802,14 @@ static void win32_stop_timer(struct qemu_alarm_timer *t);
static int unix_start_timer(struct qemu_alarm_timer *t);
static void unix_stop_timer(struct qemu_alarm_timer *t);
+#ifdef DYNAMIC_TICKS
+
+static int dynticks_start_timer(struct qemu_alarm_timer *t);
+static void dynticks_stop_timer(struct qemu_alarm_timer *t);
+static void dynticks_rearm_timer(struct qemu_alarm_timer *t);
+
+#endif
+
#ifdef __linux__
static int hpet_start_timer(struct qemu_alarm_timer *t);
@@ -785,16 +823,19 @@ static void rtc_stop_timer(struct qemu_alarm_timer *t);
#endif /* _WIN32 */
static struct qemu_alarm_timer alarm_timers[] = {
+#ifndef _WIN32
+#ifdef DYNAMIC_TICKS
+{dynticks, ALARM_FLAG_DYNTICKS, dynticks_start_timer,
dynticks_stop_timer, dynticks_rearm_timer, NULL},
+#endif
#ifdef __linux__
/* HPET - if available - is preferred */
-{hpet, hpet_start_timer, hpet_stop_timer, NULL},
+{hpet, 0, hpet_start_timer, hpet_stop_timer, NULL, NULL},
/* ...otherwise try RTC */
-{rtc, rtc_start_timer, rtc_stop_timer, NULL},
+{rtc, 0, rtc_start_timer, rtc_stop_timer, NULL, NULL},
#endif
-#ifndef _WIN32
-{unix, unix_start_timer, unix_stop_timer, NULL},
+{unix, 0, unix_start_timer, unix_stop_timer, NULL, NULL},
#else
-{win32, win32_start_timer, win32_stop_timer, alarm_win32_data},
+{win32, 0, win32_start_timer, win32_stop_timer, NULL, alarm_win32_data},
#endif
{NULL, }
};
@@ -913,6 +954,8 @@ void qemu_del_timer(QEMUTimer *ts)
}
pt = t-next;
}
+
+qemu_rearm_alarm_timer(alarm_timer);
}
/* modify the current timer so that it will be fired when current_time
@@ -972,6 +1015,7 @@ static void qemu_run_timers(QEMUTimer **ptimer_head,
int64_t current_time)
/* run the callback (the timer list can be modified) */
ts-cb(ts-opaque);
}
+qemu_rearm_alarm_timer(alarm_timer);
}
int64_t qemu_get_clock(QEMUClock *clock)
@@ -1079,7 +1123,8 @@ static void host_alarm_handler(int host_signum)
last_clock = ti;
}
#endif
-if (qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
+if (alarm_has_dynticks(alarm_timer) ||
+qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
qemu_get_clock(vm_clock)) ||
qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock))) {
@@ -1207,6 +1252,97 @@ static void rtc_stop_timer(struct qemu_alarm_timer *t)
#endif /* !defined(__linux__) */
+#ifdef DYNAMIC_TICKS
+static int dynticks_start_timer(struct qemu_alarm_timer *t)
+{
+struct sigevent ev;
+timer_t host_timer;
+struct sigaction act;
+
+sigfillset(act.sa_mask);
+act.sa_flags = 0;
+#if defined(TARGET_I386) defined(USE_CODE_COPY)
+act.sa_flags |= SA_ONSTACK;
+#endif
+act.sa_handler = host_alarm_handler;
+
+sigaction(SIGALRM, act, NULL);
+
+ev.sigev_value.sival_int = 0;
+ev.sigev_notify = SIGEV_SIGNAL;
[Qemu-devel] [PATCH/RFC 3/4] Add support for HPET periodic timer.
Linux operates the HPET timer in legacy replacement mode, which means that
the periodic interrupt of the CMOS RTC is not delivered (qemu won't be able
to use /dev/rtc). Add support for HPET (/dev/hpet) as a replacement for the
RTC; the periodic interrupt is delivered via SIGIO and is handled in the
same way as the RTC timer.
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
---
qemu/vl.c | 57 ++-
1 files changed, 56 insertions(+), 1 deletions(-)
diff --git a/qemu/vl.c b/qemu/vl.c
index f0b4896..0373beb 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -54,6 +54,7 @@
#include pty.h
#include malloc.h
#include linux/rtc.h
+#include linux/hpet.h
#include linux/ppdev.h
#endif
#endif
@@ -773,6 +774,9 @@ static void unix_stop_timer(struct qemu_alarm_timer *t);
#ifdef __linux__
+static int hpet_start_timer(struct qemu_alarm_timer *t);
+static void hpet_stop_timer(struct qemu_alarm_timer *t);
+
static int rtc_start_timer(struct qemu_alarm_timer *t);
static void rtc_stop_timer(struct qemu_alarm_timer *t);
@@ -782,7 +786,9 @@ static void rtc_stop_timer(struct qemu_alarm_timer *t);
static struct qemu_alarm_timer alarm_timers[] = {
#ifdef __linux__
-/* RTC - if available - is preferred */
+/* HPET - if available - is preferred */
+{hpet, hpet_start_timer, hpet_stop_timer, NULL},
+/* ...otherwise try RTC */
{rtc, rtc_start_timer, rtc_stop_timer, NULL},
#endif
#ifndef _WIN32
@@ -1117,6 +1123,55 @@ static void enable_sigio_timer(int fd)
fcntl(fd, F_SETOWN, getpid());
}
+static int hpet_start_timer(struct qemu_alarm_timer *t)
+{
+struct hpet_info info;
+int r, fd;
+
+fd = open(/dev/hpet, O_RDONLY);
+if (fd 0)
+return -1;
+
+/* Set frequency */
+r = ioctl(fd, HPET_IRQFREQ, RTC_FREQ);
+if (r 0) {
+fprintf(stderr, Could not configure '/dev/hpet' to have a 1024Hz
timer. This is not a fatal\n
+error, but for better emulation accuracy type:\n
+'echo 1024 /proc/sys/dev/hpet/max-user-freq' as root.\n);
+goto fail;
+}
+
+/* Check capabilities */
+r = ioctl(fd, HPET_INFO, info);
+if (r 0)
+goto fail;
+
+/* Enable periodic mode */
+r = ioctl(fd, HPET_EPI, 0);
+if (info.hi_flags (r 0))
+goto fail;
+
+/* Enable interrupt */
+r = ioctl(fd, HPET_IE_ON, 0);
+if (r 0)
+goto fail;
+
+enable_sigio_timer(fd);
+t-priv = (void *)fd;
+
+return 0;
+fail:
+close(fd);
+return -1;
+}
+
+static void hpet_stop_timer(struct qemu_alarm_timer *t)
+{
+int fd = (int)t-priv;
+
+close(fd);
+}
+
static int rtc_start_timer(struct qemu_alarm_timer *t)
{
int rtc_fd;
--
1.5.2.4
[Qemu-devel] [Patch] darwin-user: Compile fix for ppc targets
Hello, this should address an darwin-user issue that has been creeping in trunk for sometime. Thanks, Pierre. 601-darwin-user-fix.diff Description: Binary data
