[PATCH] Remove duplicate monitor option
For some reason the monitor option is included twice in this
datastructure. Probably a mistake during a merge. Patch also available at:
http://etud.epita.fr/~bevand_m/pub/kvm-remove-duplicate-monitor-option.patch
Signed-off-by: Marc Bevand gmail.com>
diff --git a/qemu/vl.c b/qemu/vl.c
index 7e4dce1..1c251e9 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -8008,7 +8008,6 @@ const QEMUOption qemu_options[] = {
#endif
{ "localtime", 0, QEMU_OPTION_localtime },
{ "std-vga", 0, QEMU_OPTION_std_vga },
-{ "monitor", 1, QEMU_OPTION_monitor },
{ "balloon", 1, QEMU_OPTION_balloon },
{ "vmchannel", 1, QEMU_OPTION_vmchannel },
{ "echr", HAS_ARG, QEMU_OPTION_echr },
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 01/12] expose ACPI pmtimer to userspace (/dev/pmtimer)
On Mon, Jun 02, 2008 at 09:43:20AM -0700, John Stultz wrote: > > If you migrate such a guest that has direct (ie. non-virtualized, using > > the physical hardware) pmtimer access to a different host (destination), > > you need to save the current host pmtimer value at the time of migration > > so that you can either emulate it with a proper offset or synchronize > > (wait for the destination hosts real hardware pmtimer value to be in > > sync before actually resuming guest execution) > > I'm a little wary on this, another thing to catch here as well is host > suspend-resume cycles that might reset the pmtimer. In that case (host resume from S-state) we can hold guest execution until the real hw timer is in proximity to the guests expectation, or fallback to emulation (but its not unsolvable). This problem can happen now with the TSC since kvm's suspend routine isnt saving it. Thanks for the reminder. > > > > This patch will not register the device if the chipset has an unreliable > > > > timer. > > > > > > Can we please keep that code inside of drivers/clocksource/acpi_pm.c > > > without creating a new disconnected file in drivers/char ? > > > > > > Btw, depending on the use case we might as well have a sysfs entry for > > > that. > > > > A sysfs entry sounds fine and much simpler. Should probably be a generic > > clocksource interface (so userspace can read any available clocksource) > > rather than acpi_pm specific. > > Again, I'd be hesitant to expose this stuff to userland since if the > counters reset (such as in the suspend/resume case) the applications may > not be aware. > > And if its a generic interface, we would then have to also export > frequency and mask values. It just gets messy, so I'd avoid doing > anything generic in exporting clocksources (since either userland wants > specific hardware and is aware of all the known troubles it may have, or > userland should use the existing kernel time interfaces). Good point. Will go for the acpi_pm's private sysfs file. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-1970154 ] AMD CPU + KVM BUG.. Can't Share CPU..
Bugs item #1970154, was opened at 2008-05-23 15:36 Message generated for change (Comment added) made by call518 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1970154&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: amd Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Jung (call518) Assigned to: Nobody/Anonymous (nobody) Summary: AMD CPU + KVM BUG.. Can't Share CPU.. Initial Comment: * CPU(2EA) : Quad-Core AMD Opteron(tm) Processo * TEST KVM-VERSION : KVM-63,68,69 * Total Memory : 16GB * MainMoard : TYAN S2933 ## This System's Total CPU is.. 8EA... CPU#00, CPU#01, CPU#02, .. CPU#06, CPU#07 If Running GuestOS's Numbers be more than physical CPUs Number(8).. then, All GuestOS is Crashed and QEMU Process's CPU Usage is 100%... ## Example.. == 1) total core is 8 (AMD CPU : kvm-amd Module) 2) Run 8EA Guest-OS... No Problem... 3) Additionally.. Run Guest-OS.. Over 8EA.. Then... All... or Some os Guest-OS is Crashed.. !!! and QEMU process;s CPU Usage 100% on 'top' 4) the other side, INTEL CPU (kcm-intel Moduel)... No Problem == * I guess, this problem is kvm bug that can't share physical CPUs... * Attatched Jpeg File is... Crashed Geust-OS's VNC ScreenShot. * Please.. Check.. This Problem -- >Comment By: Jung (call518) Date: 2008-06-03 12:43 Message: Logged In: YES user_id=957755 Originator: YES Problem Solved.!! MainBoard BIOS Setting.. ACPI Menu -- ACPI 1.0 ACPI 2.0 ACPI 3.0 -- Problem : ACPI 2.0 (3.0) No Problem : ACPI 1.0 ... ... This...is KVM's ACPI Bug?? -- Comment By: Jung (call518) Date: 2008-05-30 15:22 Message: Logged In: YES user_id=957755 Originator: YES in case e1000 no problem is KVM+68 + KVM Patch(http://www.mail-archive.com/[EMAIL PROTECTED]/msg01701.html) -- Comment By: Jung (call518) Date: 2008-05-30 15:10 Message: Logged In: YES user_id=957755 Originator: YES in case NIC Model=e1000... Problem.. but in case NIC model=rtl8139 No Problem... KVM QEMU Works...Fine.!! -- Comment By: Jung (call518) Date: 2008-05-30 15:05 Message: Logged In: YES user_id=957755 Originator: YES kvm: 10588: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop kvm: 10588: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop kvm: 10588: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop kvm: 2459: cpu0 unhandled rdmsr: 0x417 kvm: 2459: cpu0 unhandled rdmsr: 0xc400 kvm: 2459: cpu0 unhandled rdmsr: 0xc401 kvm: 2459: cpu0 unhandled rdmsr: 0xc402 kvm: 2459: cpu0 unhandled rdmsr: 0xc403 kvm: 2459: cpu0 unhandled rdmsr: 0xc404 kvm: 2459: cpu0 unhandled rdmsr: 0xc405 kvm: 2459: cpu0 unhandled rdmsr: 0xc406 kvm: 2459: cpu0 unhandled rdmsr: 0xc407 eth1: topology change detected, propagating vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin -- Comment By: Jung (call518) Date: 2008-05-30 14:41 Message: Logged In: YES user_id=957755 Originator: YES kvm: 10588: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop kvm: 10588: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop kvm: 10588: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop kvm: 2459: cpu0 unhandled rdmsr: 0x417 kvm: 2459: cpu0 unhandled rdmsr: 0xc400 kvm: 2459: cpu0 unhandled rdmsr: 0xc401 kvm: 2459: cpu0 unhandled rdmsr: 0xc402 kvm: 2459: cpu0 unhandled rdmsr: 0xc403 kvm: 2459: cpu0 unhandled rdmsr: 0xc404 kvm: 2459: cpu0 unhandled rdmsr: 0xc405 kvm: 2459: cpu0 unhandled rdmsr: 0xc406 kvm: 2459: cpu0 unhandled rdmsr: 0xc407 eth1: topology change detected, propagating vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin vcpu not ready for apic_round_robin
Re: kvm, hal, and evdev
Alan Kennedy wrote: Anthony Liguori codemonkey.ws> writes: How are you interacting with the guest? via SDL? If so, do other SDL applications work correctly? Are you using evdev in the host or in the guest? Regards, Anthony Liguori Thanks for the response. I'm using SDL. I have no other SDL applications. If you know of a easy to install SDL application to use as a test please let me know. The host is running evdev, and the guest is Windows XP. Historically, SDL has had some trouble processing input events. I wouldn't be surprised if it's evdev support was buggy. See if you see have problems using -vnc and connecting with a vnc client (preferrably, vinagre or gvncviewer). Regards, Anthony Liguori Thanks again, Alan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm causing memory corruption? now 2.6.26-rc4
On Mon, 2008-06-02 at 15:30 -0700, Dave Hansen wrote: > On Thu, 2008-03-27 at 16:59 +0200, Avi Kivity wrote: > > Dave Hansen wrote: > > > On Thu, 2008-03-27 at 12:10 +0200, Avi Kivity wrote: > > >> btw, is this with >= 4GB RAM on the host? > > > > > > Well, are you asking whether I have PAE on or not? :) > > > > No, I'm asking whether there is a possibility of address truncation :) > > > > PAE by itself doesn't affect kvm much, as it always runs the guest in > > pae mode. > > > > Can you try running with mem=2000M or something? > > I have a few more data points on this. Sorry for the massive delay from > the last report -- I'm being a crappy bug reporter. But, this is on my > one and only laptop which makes it a serious pain to diagnose. I also > didn't have a hardware serial console on it before, which I do now. > This is all on 2.6.26-rc4-01549-g1beee8d. > > Adding the mem= does not help at all. But, it is all a bit more > diagnosable now than a month or two ago. I turned on all of the kernel > debugging that I could get my grubby little hands on. It now oopses > quite consistently when kvm runs instead of after. Here's a collection > of oopses that I captured after setting up a serial line: > > http://sr71.net/~dave/kvm-oops1.txt > > After collecting all those, I turned on CONFIG_DEBUG_HIGHMEM and the > oopses miraculously stopped. But, the guest hung (for at least 5 > minutes or so) during windows bootup, pegging my host CPU. Most of the > CPU was going to klogd, so I checked dmesg. > > I was seeing messages like this > > [ 428.918108] kvm_handle_exit: unexpected, valid vectoring info and exit > reason is 0x9 > > And quite a few of them, like 100,000/sec. That's why klogd was pegging > the CPU. Any idea on a next debugging step? I followed these steps, and can now boot a vm. But, causing the host crashes is still a pretty bad bug. I would imagine turning ACPI back on will let me reproduce if necessary. http://kvm.qumranet.com/kvmwiki/Windows_ACPI_Workaround -- Dave -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New version of my kvmctl script
i got it running under non-root. first, i used to have a group 'kvm', and /dev/net/tun is writable by this group. so, i made the 'temp' directories (/var/run/kvmctl/, and a couple extra) also writable by the same group. then, i added a couple calls to "tunctl" to pre-create the tap device before running kvm. i also added a "sdl" option to the "start" command, it simply removes the VNC parameters from the startup line. as i feel VNC is too clumsy for a workstation, but i think it should be an 'ephemeral' option, not for the config file. i'll post my diffs tomorrow, i have to run now. -- Javier -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Fwd: Re: kvm causing memory corruption? now 2.6.26-rc4]
Oops, sent to the old list. Please reply-all to the LKML version if you need to reply... Forwarded Message From: Dave Hansen <[EMAIL PROTECTED]> To: Avi Kivity <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>, kvm-devel <[EMAIL PROTECTED]>, Anthony N. Liguori [imap] <[EMAIL PROTECTED]> Subject: Re: kvm causing memory corruption? now 2.6.26-rc4 Date: Mon, 02 Jun 2008 15:30:15 -0700 On Thu, 2008-03-27 at 16:59 +0200, Avi Kivity wrote: > Dave Hansen wrote: > > On Thu, 2008-03-27 at 12:10 +0200, Avi Kivity wrote: > >> btw, is this with >= 4GB RAM on the host? > > > > Well, are you asking whether I have PAE on or not? :) > > No, I'm asking whether there is a possibility of address truncation :) > > PAE by itself doesn't affect kvm much, as it always runs the guest in > pae mode. > > Can you try running with mem=2000M or something? I have a few more data points on this. Sorry for the massive delay from the last report -- I'm being a crappy bug reporter. But, this is on my one and only laptop which makes it a serious pain to diagnose. I also didn't have a hardware serial console on it before, which I do now. This is all on 2.6.26-rc4-01549-g1beee8d. Adding the mem= does not help at all. But, it is all a bit more diagnosable now than a month or two ago. I turned on all of the kernel debugging that I could get my grubby little hands on. It now oopses quite consistently when kvm runs instead of after. Here's a collection of oopses that I captured after setting up a serial line: http://sr71.net/~dave/kvm-oops1.txt After collecting all those, I turned on CONFIG_DEBUG_HIGHMEM and the oopses miraculously stopped. But, the guest hung (for at least 5 minutes or so) during windows bootup, pegging my host CPU. Most of the CPU was going to klogd, so I checked dmesg. I was seeing messages like this [ 428.918108] kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9 And quite a few of them, like 100,000/sec. That's why klogd was pegging the CPU. Any idea on a next debugging step? -- Dave -- Dave -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New version of my kvmctl script
On June 2, 2008 11:20 am FinnTux N/A wrote: > 2008/6/2 Freddie Cash <[EMAIL PROTECTED]>: > > You may want to rename the script. There's already a kvmctl (at > > least on Debian) in the /usr/sbin directory that is used for testing. > > It comes with some debian kvm packages? It's part of the kvm package in Lenny (kvm-60) and Sid (kvm-69). Sorry, it's installed under /usr/bin, not /usr/sbin. Here's the output of --help: # /usr/bin/kvmctl --help Usage: /usr/bin/kvmctl [OPTIONS] [bootstrap] flatfile KVM test harness. -s, --smp=NUM create a VM with NUM virtual CPUs -p, --protected-mode start VM in protected mode -m, --memory=NUM[GMKB] allocate NUM memory for virtual machine. A suffix can be used to change the unit (default: `M') -h, --help display this help screen and exit Report bugs to <[EMAIL PROTECTED]>. Considering this is a test harness and not a control program, perhaps it should be renamed in the kvm sources/builds, to something more appropriate like kvmtest. > Anyways, I was afraid of these naming issues. kvmctl is pretty generic > name. Any suggestions? I'd prefer to keep the management/control scripts/apps named kvmctl, as that's easier to remember and fits with things like sysctl, apachectl, brctl, and other similar apps. -- Freddie Cash [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New version of my kvmctl script
After quick googling I renamed the script/product/whatever to virmactl (VIrtual MAchine ConTroL). Download: http://81.209.59.133/virmactl-0.0.1.tar.gz -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New version of my kvmctl script
2008/6/2 Freddie Cash <[EMAIL PROTECTED]>: > You may want to rename the script. There's already a kvmctl (at least on > Debian) in the /usr/sbin directory that is used for testing. It comes with some debian kvm packages? Anyways, I was afraid of these naming issues. kvmctl is pretty generic name. Any suggestions? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New version of my kvmctl script
On June 2, 2008 10:29 am you wrote: > For some reason I couldn't reply to my previous post... > > But here is a new version. Now with version number! :) > > Changes: > - includes init script /etc/initd.d/kvm which starts and stops virtual > machines when booting and shutting down the host. Shutting down the > guest is done by sending "system_powerdown" to the guest. If the guest > doesn't powerdown in 120 seconds (adjustable) it will be killed. You should rename the init script. At least on Debian systems, there's already an /etc/init.d/kvm script that auto-loads the kvm modules. > - kvmctl can set vm to start or not to start during boot (kvmctl > vmname onboot yes|no). Without yes/no script shows whether VM is > started on boot or not. You may want to rename the script. There's already a kvmctl (at least on Debian) in the /usr/sbin directory that is used for testing. I ran into this issue when I named my management script kvmctl, and /usr/sbin is ahead of /usr/local/sbin in the default PATH. -- Freddie Cash [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
New version of my kvmctl script
For some reason I couldn't reply to my previous post... But here is a new version. Now with version number! :) Changes: - includes init script /etc/initd.d/kvm which starts and stops virtual machines when booting and shutting down the host. Shutting down the guest is done by sending "system_powerdown" to the guest. If the guest doesn't powerdown in 120 seconds (adjustable) it will be killed. - kvmctl can set vm to start or not to start during boot (kvmctl vmname onboot yes|no). Without yes/no script shows whether VM is started on boot or not. Download: http://81.209.59.133/kvmctl-0.0.1.tar.gz -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] KVM/userspace: Support for assigning PCI devices to guest
On Monday 02 June 2008 19:27:31 Anthony Liguori wrote:
> Amit Shah wrote:
> > We can assign a device from the host machine to a guest. The original
> > code comes from Neocleus.
> >
> > A new command-line option, -pcidevice is added.
> > For example, to invoke it for an Ethernet device sitting at
> > PCI bus:dev.fn 04:08.0 with host IRQ 18, use this:
> >
> > -pcidevice Ethernet/04:08.0-18
>
> Why is it necessary to specify the device type and the IRQ? Shouldn't
> that all be discoverable?
The first string isn't the device type, just some string passed to identify it
in the debug logs.
The IRQ is needed for the irqhook module. Currently, we use it when using the
in-kernel irqchip as well, but that should be replaced soon.
> > The host ethernet driver is to be removed before doing the passthrough.
> >
> > If kvm uses the in-kernel irqchip, interrupts are routed to
> > the guest via the kvm module (accompanied kernel changes are necessary).
> > If -no-kvm-irqchip is used, the 'irqhook' module, also included here,
> > is to be used.
>
> We should drop the irqhook module entirely. It seems unlikely that it
> will be received well on LKML.
It's not planned for submission. It's needed by a few for some cases and it's
going to be around only as a fallback.
> > +#ifdef KVM_CAP_PCI_PASSTHROUGH
> > +/*!
> > + * \brief Notifies host kernel about assigning a PCI device to the guest
> > + *
> > + * Used for PCI passthrough, this function notifies the host kernel
> > + * about the assigning of the physical PCI device and the guest PCI
> > + * parameters. Also called when the guest updates the irq number for a
> > + * passthrough device
> > + *
> > + * \param kvm Pointer to the current kvm_context
> > + * \param pci_pt_dev Parameters like irq, PCI bus, devfn number, etc
> > + */
> > +int kvm_assign_pci_pt_device(kvm_context_t kvm,
> > +struct kvm_pci_passthrough_dev *pci_pt_dev);
>
> Is such a high level interface really required? We need to forward one
> (or potentially more) IRQs to the guest and we need to setup VT-d.
> Shouldn't these be separate operations?
Essentially, we're just notifying the host kernel about a guest device being
updated. For the first time, it's also about telling the host of a new device
being registered. Subsequent times (for the same device), it'll just be
updates about guest IRQs being changed.
Logically, these are two separate things as you mention, but in effect, it's
the same thing, passing around the same structure.
> > static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
> > @@ -1144,6 +1147,7 @@ static void ioapic_mem_writel(void *opaque,
> > target_phys_addr_t addr, uint32_t va } else {
> > s->ioredtbl[index] &= ~0xULL;
> > s->ioredtbl[index] |= val;
> > +pt_set_vector(index, (val << 24) >> 24);
>
> Is this an attempt to sign extend a 24-bit value? It's very odd looking.
You're right; most of this code is from the original developers and I've not
touched it yet. I've just put the code that needs kvm into kvm_enabled()
blocks and that's only limited to the part that makes this code work with
in-kernel irqchip enabled.
> > @@ -997,6 +998,9 @@ static void pc_init1(ram_addr_t ram_size, int
> > vga_ram_size, }
> > }
> >
> > +/* Initialize pass-through */
> > +pt_init(pci_bus);
> > +
>
> Each pass-through device should be treated as a special PCI device.
> This implies that we should be looping in pc_init1() and creating each
> pass through device based on user-provided parameters. A side effect of
> this is that it will make pci_add much easier to get working which is
> something that's missing from this series.
I've not seen the pci_add codepath; it will be nice if we get that supported.
> > +typedef __u64 resource_size_t;
> > +#define __deprecated
> > +#include
>
> Neither of these look very good. Why are we including ioport.h?
ioport is needed for some definitions -- IORESOURCE_MEM, IORESOURCE_PREFETCH,
etc. The __deprecated is there to make ioport.h compile succeed.
However, there should be a qemu equivalent to the #defines we need.
> > +#include "pci-passthrough.h"
> > +#include "irq.h"
> > +
> > +#include "qemu-kvm.h"
> > +#include
> > +extern kvm_context_t kvm_context;
> > +extern FILE *logfile;
>
> Please avoid open usage of kvm_context.
We already include qemu-kvm.h and this extern isn't needed at all.
> > +#define pt_ioport_read(suffix)
> > \
> > +uint32_t pt_ioport_read##suffix(void *opaque, uint32_t addr)
> > \
> > +{ \
> > + pt_region_t *r_access = (pt_region_t *)opaque; \
> > + uint32_t r_pio = (addr - r_access->e_physbase) \
> > + + (unsigned long)r_access->r_virtbase; \
> > + uint32_t value = in##suffix(r_pio);
Re: [patch 01/12] expose ACPI pmtimer to userspace (/dev/pmtimer)
On Sun, 2008-06-01 at 14:56 -0300, Marcelo Tosatti wrote: > On Sun, Jun 01, 2008 at 06:34:27PM +0200, Thomas Gleixner wrote: > > On Thu, 29 May 2008, Marcelo Tosatti wrote: > > > KVM wishes to allow direct guest access to the ACPI pmtimer. In that > > > case QEMU/KVM has to read the current value for migration, so the proper > > > syncing can be done on the destination. > > > > I don't understand from the above which problem you are trying to > > solve. Which pmtimer is read out, the one of the host (physical > > hardware) or the one of the guest (emulated hardware) ? What is synced > > at the destination ? > > Problem is this: > > We want to allow guests to directly access the hosts pmtimer (by using > the I/O bitmap feature in VMX/SVM hardware). The advantage of doing it > is that no VMExits are necessary for guest pmtimer reads (which happen > often if we inform the guest that ACPI C1 state is supported, or if the > workload is gettimeofday() intensive). > > If you migrate such a guest that has direct (ie. non-virtualized, using > the physical hardware) pmtimer access to a different host (destination), > you need to save the current host pmtimer value at the time of migration > so that you can either emulate it with a proper offset or synchronize > (wait for the destination hosts real hardware pmtimer value to be in > sync before actually resuming guest execution) I'm a little wary on this, another thing to catch here as well is host suspend-resume cycles that might reset the pmtimer. > > > This patch will not register the device if the chipset has an unreliable > > > timer. > > > > Can we please keep that code inside of drivers/clocksource/acpi_pm.c > > without creating a new disconnected file in drivers/char ? > > > > Btw, depending on the use case we might as well have a sysfs entry for that. > > A sysfs entry sounds fine and much simpler. Should probably be a generic > clocksource interface (so userspace can read any available clocksource) > rather than acpi_pm specific. Again, I'd be hesitant to expose this stuff to userland since if the counters reset (such as in the suspend/resume case) the applications may not be aware. And if its a generic interface, we would then have to also export frequency and mask values. It just gets messy, so I'd avoid doing anything generic in exporting clocksources (since either userland wants specific hardware and is aware of all the known troubles it may have, or userland should use the existing kernel time interfaces). thanks -john -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm-devel] performance with guests running 2.4 kernels (specifically RHEL3)
Avi Kivity wrote: > David S. Ahern wrote: >>> I haven't been able to reproduce this: >>> >>> [EMAIL PROTECTED] root]# ps -elf | grep -E 'memuser|kscand' 1 S root 7 1 1 75 0- 0 schedu 10:07 ? 00:00:26 [kscand] 0 S root 1464 1 1 75 0- 196986 schedu 10:20 pts/0 00:00:21 ./memuser 768M 120 5 300 0 S root 1465 1 0 75 0- 98683 schedu 10:20 pts/0 00:00:10 ./memuser 384M 300 10 600 0 S root 2148 1293 0 75 0- 922 pipe_w 10:48 pts/0 00:00:00 grep -E memuser|kscand >>> The workload has been running for about half an hour, and kswapd cpu >>> usage doesn't seem significant. This is a 2GB guest running with my >>> patch ported to kvm.git HEAD. Guest is has 2G of memory. >>> >>> >> >> I'm running on the per-page-pte-tracking branch, and I am still seeing >> it. >> I doubt you want to sit and watch the screen for an hour, so install >> sysstat if not already, change the sample rate to 1 minute >> (/etc/cron.d/sysstat), let the server run for a few hours and then run >> 'sar -u'. You'll see something like this: >> >> 10:12:11 AM LINUX RESTART >> >> 10:13:03 AM CPU %user %nice %system %iowait %idle >> 10:14:01 AM all 0.08 0.00 2.08 0.35 97.49 >> 10:15:03 AM all 0.05 0.00 0.79 0.04 99.12 >> 10:15:59 AM all 0.15 0.00 1.52 0.06 98.27 >> 10:17:01 AM all 0.04 0.00 0.69 0.04 99.23 >> 10:17:59 AM all 0.01 0.00 0.39 0.00 99.60 >> 10:18:59 AM all 0.00 0.00 0.12 0.02 99.87 >> 10:20:02 AM all 0.18 0.00 14.62 0.09 85.10 >> 10:21:01 AM all 0.71 0.00 26.35 0.01 72.94 >> 10:22:02 AM all 0.67 0.00 10.61 0.00 88.72 >> 10:22:59 AM all 0.14 0.00 1.80 0.00 98.06 >> 10:24:03 AM all 0.13 0.00 0.50 0.00 99.37 >> 10:24:59 AM all 0.09 0.00 11.46 0.00 88.45 >> 10:26:03 AM all 0.16 0.00 0.69 0.03 99.12 >> 10:26:59 AM all 0.14 0.00 10.01 0.02 89.83 >> 10:28:03 AM all 0.57 0.00 2.20 0.03 97.20 >> Average: all 0.21 0.00 5.55 0.05 94.20 >> >> >> every one of those jumps in %system time directly correlates to kscand >> activity. Without the memuser programs running the guest %system time >> is <1%. The point of this silly memuser program is just to use high >> memory -- let it age, then make it active again, sit idle, repeat. If >> you run kvm_stat with -l in the host you'll see the jump in pte >> writes/updates. An intern here added a timestamp to the kvm_stat >> output for me which helps to directly correlate guest/host data. >> >> >> I also ran my real guest on the branch. Performance at boot through >> the first 15 minutes was much better, but I'm still seeing recurring >> hits every 5 minutes when kscand kicks in. Here's the data from the >> guest for the first one which happened after 15 minutes of uptime: >> >> active_anon_scan: HighMem, age 11, count[age] 24886 -> 5796, direct >> 24845, dj 59 >> >> active_anon_scan: HighMem, age 7, count[age] 47772 -> 21289, direct >> 40868, dj 103 >> >> active_anon_scan: HighMem, age 3, count[age] 91007 -> 329, direct >> 45805, dj 1212 >> >> > > We touched 90,000 ptes in 12 seconds. That's 8,000 ptes per second. > Yet we see 180,000 page faults per second in the trace. > > Oh! Only 45K pages were direct, so the other 45K were shared, with > perhaps many ptes. We shoud count ptes, not pages. > > Can you modify page_referenced() to count the numbers of ptes mapped (1 > for direct pages, nr_chains for indirect pages) and print the total > deltas in active_anon_scan? > Here you go. I've shortened the line lengths to get them to squeeze into 80 columns: anon_scan, all HighMem zone, 187,910 active pages at loop start: count[12] 21462 -> 230, direct 20469, chains 3479, dj 58 count[11] 1338 -> 1162, direct 227, chains 26144, dj 59 count[8] 29397 -> 5410, direct 26115, chains 27617, dj 117 count[4] 35804 -> 25556, direct 31508, chains 82929, dj 256 count[3] 2738 -> 2207, direct 2680, chains 58, dj 7 count[0] 92580 -> 89509, direct 75024, chains 262834, dj 726 (age number is the index in []) cache_scan, all HighMem zone, 48,298 active pages at loop start: count[12] 3642 -> 2982, direct 499, chains 20022, dj 44 count[8] 11254 -> 11187, direct 7189, chains 9854, dj 37 count[4] 15709 -> 15702, direct 5071, chains 9388, dj 31 (with anon_cache_count bug fixed) If you sum the direct pages and the chains count for each row, convert dj into dt (divided by HZ = 100) you get: ( 20469 + 3479 ) / 0.58 = 41289 ( 227 + 26144 )
Re: [patch 00/12] fake ACPI C2 emulation v2
On Sun, Jun 01, 2008 at 12:21:29PM +0300, Avi Kivity wrote: > Marcelo Tosatti wrote: >> Addressing comments on the previous patchset, follows: >> >> - Same fake C2 emulation >> - /dev/pmtimer >> - Support for multiple IO bitmap pages + userspace interface >> - In-kernel ACPI pmtimer emulation >> >> Tested with Linux and WinXP guests. Also tested migration. >> > > Do you have any performance numbers, comparing qemu/kernel/passthrough? Test is 1 million gettimeofday calls, Xeon 1.60GHz with 4MB L2. guest (qemu emulation): cycles:1189759332 guest (in-kernel emulation): cycles:628046412 guest (direct pmtimer): cycles:230372934 host (TSC): cycles:14862774 > [Real review will be delayed as I am travelling; will try to do as much as > I can] OK! -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Benchmarking on CentOS 5
On Mon, 2008-06-02 at 14:35 +0530, Amit Shah wrote: > On Friday 30 May 2008 23:00:41 Farkas Levente wrote: > > this is out production server at the development department (10-15) > > people using it so actually if i tell them that i'll stop the host and > > all guests for max an hour it's acceptable, but more not really. it's > > run it type programs. from my experience in the last 6-12 months is that > > kvm is not production ready. as you can read from this list there are > > far too many change day-by-day which are very core. and this comes from > > the current state of kvm. which indicate that rh can't include in there > > You'll find the most stable version of kvm in the kernel that your > distribution ships. Linux-2.6.x (where x > 20) should also be stable. The > development on kvm will continue to proceed at a fast pace, so you'll see > several kvm releases and this, as a result, is bound to bring in a few new > bugs in each iteration. > > > imho the biggest problem with the current development of kvm that there > > is not a stable releases which is somewhat related to the current > > release number. eg kvm-0.5.x kvm-0.6.x would be better. but currently > > So the short answer is: if you're looking for a stable version of kvm, look > at > a kernel.org kernel or the kvm version provided to you by your distribution. > > > kvm development is so fast that keep 2-3 parallel branch where there is > > a development and stable release seems to too much work. > > so to answer to your question i don't know:-( > > The "stable" branch of kvm is the one in the most-recently available Linux > kernel from kernel.org. kvm.git is the development version. In the near future we'll publish a stable branch. There are actually 2 repositories: kernel repo, based on the latest kernel - 2.6.26 and a userspace repository that will be based on kvm-68. The idea is to maintain the above repos together and only apply bug fixes. New features will come with every next kernel release. We're in the process of creating an automatic test framework for kvm. It will be open source framework based on autotest and similar to Anthony's kvmtest. It will help stabilizing both the 'stable' branch and the master. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Control script for kvm
On Sat, May 31, 2008 at 2:41 PM, FinnTux N/A <[EMAIL PROTECTED]> wrote: > I think pretty much everyone has made their own so here is mine. looks pretty nice; i'm reworking my setup to adapt to yours. (currently only on dev workstations, but soon will be a couple of servers (replacing VMWare server)). 1 question: you set -std-vga; is there any advantage for this? or is it mostly for higer/wider resolutions? since my guests are either servers or test machines, i really don't have a use for screens bigger than 1024x768 > TODO: > - "ONBOOT" flag to start certain virtual machines on boot. Also > gracefully shut running vms on reboot/shutdown of host 1 idea: instead of a flag, have a 'dirstart' command, that starts all machines (or links) from a given directory. then add a "kvmctl dirstart /etc/kvmctl/startup" to /etc/rc.local, or even simpler: for vm in /etc/kvmctl/startup/*.cfg; do kvmctl start $vm; done -- Javier -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] KVM/userspace: Support for assigning PCI devices to guest
Amit Shah wrote: From: Or Sagi <[EMAIL PROTECTED]> From: Nir Peleg <[EMAIL PROTECTED]> From: Amit Shah <[EMAIL PROTECTED]> From: Glauber de Oliveira Costa <[EMAIL PROTECTED]> We can assign a device from the host machine to a guest. The original code comes from Neocleus. Also, in the future, please split this patch up. It has a lot going on at the moment. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] KVM/userspace: Support for assigning PCI devices to guest
Amit Shah wrote:
From: Or Sagi <[EMAIL PROTECTED]>
From: Nir Peleg <[EMAIL PROTECTED]>
From: Amit Shah <[EMAIL PROTECTED]>
From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
We can assign a device from the host machine to a guest. The original code comes
from Neocleus.
A new command-line option, -pcidevice is added.
For example, to invoke it for an Ethernet device sitting at
PCI bus:dev.fn 04:08.0 with host IRQ 18, use this:
-pcidevice Ethernet/04:08.0-18
Why is it necessary to specify the device type and the IRQ? Shouldn't
that all be discoverable?
The host ethernet driver is to be removed before doing the passthrough.
If kvm uses the in-kernel irqchip, interrupts are routed to
the guest via the kvm module (accompanied kernel changes are necessary).
If -no-kvm-irqchip is used, the 'irqhook' module, also included here,
is to be used.
We should drop the irqhook module entirely. It seems unlikely that it
will be received well on LKML.
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index 63183b8..0dd4334 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -12,6 +12,7 @@
#endif
#include
+#include
#include
@@ -626,4 +627,19 @@ int kvm_enable_vapic(kvm_context_t kvm, int vcpu, uint64_t vapic);
#endif
+#ifdef KVM_CAP_PCI_PASSTHROUGH
+/*!
+ * \brief Notifies host kernel about assigning a PCI device to the guest
+ *
+ * Used for PCI passthrough, this function notifies the host kernel
+ * about the assigning of the physical PCI device and the guest PCI
+ * parameters. Also called when the guest updates the irq number for a
+ * passthrough device
+ *
+ * \param kvm Pointer to the current kvm_context
+ * \param pci_pt_dev Parameters like irq, PCI bus, devfn number, etc
+ */
+int kvm_assign_pci_pt_device(kvm_context_t kvm,
+struct kvm_pci_passthrough_dev *pci_pt_dev);
Is such a high level interface really required? We need to forward one
(or potentially more) IRQs to the guest and we need to setup VT-d.
Shouldn't these be separate operations?
+#endif
#endif
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 66c1fb1..1c9d445 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -615,6 +615,7 @@ OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o extboot.o
+OBJS+= pci-passthrough.o
ifeq ($(USE_KVM_PIT), 1)
OBJS+= i8254-kvm.o
endif
diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c
index a14cab2..3f83e64 100644
--- a/qemu/hw/apic.c
+++ b/qemu/hw/apic.c
@@ -23,6 +23,8 @@
#include "qemu-kvm.h"
+#include "pci-passthrough.h"
+
//#define DEBUG_APIC
//#define DEBUG_IOAPIC
@@ -389,6 +391,7 @@ static void apic_eoi(APICState *s)
/* XXX: send the EOI packet to the APIC bus to allow the I/O APIC to
set the remote IRR bit for level triggered interrupts. */
apic_update_irq(s);
+pt_ack_mirq(isrv);
}
static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
@@ -1144,6 +1147,7 @@ static void ioapic_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_t va
} else {
s->ioredtbl[index] &= ~0xULL;
s->ioredtbl[index] |= val;
+pt_set_vector(index, (val << 24) >> 24);
Is this an attempt to sign extend a 24-bit value? It's very odd looking.
}
ioapic_service(s);
}
diff --git a/qemu/hw/isa.h b/qemu/hw/isa.h
index 89b3004..c720f5e 100644
--- a/qemu/hw/isa.h
+++ b/qemu/hw/isa.h
@@ -1,5 +1,7 @@
/* ISA bus */
+#include "hw.h"
+
extern target_phys_addr_t isa_mem_base;
int register_ioport_read(int start, int length, int size,
diff --git a/qemu/hw/pc.c b/qemu/hw/pc.c
index da4a608..a9b7e60 100644
--- a/qemu/hw/pc.c
+++ b/qemu/hw/pc.c
@@ -32,6 +32,7 @@
#include "smbus.h"
#include "boards.h"
#include "console.h"
+#include "pci-passthrough.h"
#include "qemu-kvm.h"
@@ -997,6 +998,9 @@ static void pc_init1(ram_addr_t ram_size, int vga_ram_size,
}
}
+/* Initialize pass-through */
+pt_init(pci_bus);
+
Each pass-through device should be treated as a special PCI device.
This implies that we should be looping in pc_init1() and creating each
pass through device based on user-provided parameters. A side effect of
this is that it will make pci_add much easier to get working which is
something that's missing from this series.
rtc_state = rtc_init(0x70, i8259[8]);
register_ioport_read(0x92, 1, 1, ioport92_read, NULL);
diff --git a/qemu/hw/pci-passthrough.c b/qemu/hw/pci-passthrough.c
new file mode 100644
index 000..b1413af
--- /dev/null
+++ b/qemu/hw/pci-passthrough.c
@@ -0,0 +1,704 @@
+/*
+ * Copyright (c) 2007, Neocleus Corporation.
+ *
+ * This program is free software; you can redistribute it and
[ kvm-Bugs-1981866 ] Booting WXP SP3 fail
Bugs item #1981866, was opened at 2008-06-02 11:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1981866&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kubrick (kubrick_fr) Assigned to: Nobody/Anonymous (nobody) Summary: Booting WXP SP3 fail Initial Comment: Hello. When booting WXP 32bits SP3 with kvm-69, a BSOD appears before the login screen : "Driver unloaded without cancelling pending operations" The system starts properly with the -no-kvm switch or in fail-safe mode with kvm acceleration enabled. I first thought that it was the virtio NIC driver causing problem but it does the same with the Realtech one, and boots with the virtio NIC in failsafe mode with network support. Reverting the SP3 installation back to SP2 makes it work again. Cheers. Kubrick. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1981866&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Benchmarking on CentOS 5
On Friday 30 May 2008 23:00:41 Farkas Levente wrote: > this is out production server at the development department (10-15) > people using it so actually if i tell them that i'll stop the host and > all guests for max an hour it's acceptable, but more not really. it's > run it type programs. from my experience in the last 6-12 months is that > kvm is not production ready. as you can read from this list there are > far too many change day-by-day which are very core. and this comes from > the current state of kvm. which indicate that rh can't include in there You'll find the most stable version of kvm in the kernel that your distribution ships. Linux-2.6.x (where x > 20) should also be stable. The development on kvm will continue to proceed at a fast pace, so you'll see several kvm releases and this, as a result, is bound to bring in a few new bugs in each iteration. > imho the biggest problem with the current development of kvm that there > is not a stable releases which is somewhat related to the current > release number. eg kvm-0.5.x kvm-0.6.x would be better. but currently So the short answer is: if you're looking for a stable version of kvm, look at a kernel.org kernel or the kvm version provided to you by your distribution. > kvm development is so fast that keep 2-3 parallel branch where there is > a development and stable release seems to too much work. > so to answer to your question i don't know:-( The "stable" branch of kvm is the one in the most-recently available Linux kernel from kernel.org. kvm.git is the development version. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] KVM/userspace: Support for assigning PCI devices to guest
On Monday 02 June 2008 12:48:50 Han, Weidong wrote: > Amit Shah wrote: > > The host ethernet driver is to be removed before doing the > > passthrough. > > This operation is rough. Do you have any plan to improve it? For > example, don't load drivers for the devices which will be assigned to > guests when host booting, or ideally unbind driver devices dynamically > before assignment. I have a few options in mind: - failing registration of a device and loading of guest if an already-loaded driver is found - Not worry about this case and leave it to the administrator The first option can be enforced by calls to pci_enable_device() and pci_request_regions(). This can solve the problem of assigning multiple devices of the same guest as well. Dynamically unbinding devices is prone to a lot of errors and assumptions and such policy shouldn't be enforced. We should either fail the assignment and let the administrator take care of doing the right thing and start the guest or just not launch the guest at all. Amit. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] KVM/userspace: Support for assigning PCI devices to guest
Amit Shah wrote: > From: Or Sagi <[EMAIL PROTECTED]> > From: Nir Peleg <[EMAIL PROTECTED]> > From: Amit Shah <[EMAIL PROTECTED]> > From: Glauber de Oliveira Costa <[EMAIL PROTECTED]> > > We can assign a device from the host machine to a guest. The original > code comes > from Neocleus. > > A new command-line option, -pcidevice is added. > For example, to invoke it for an Ethernet device sitting at > PCI bus:dev.fn 04:08.0 with host IRQ 18, use this: > > -pcidevice Ethernet/04:08.0-18 > > The host ethernet driver is to be removed before doing the > passthrough. This operation is rough. Do you have any plan to improve it? For example, don't load drivers for the devices which will be assigned to guests when host booting, or ideally unbind driver devices dynamically before assignment. Randy (Weidong) > > If kvm uses the in-kernel irqchip, interrupts are routed to > the guest via the kvm module (accompanied kernel changes are > necessary). > If -no-kvm-irqchip is used, the 'irqhook' module, also included here, > is to be used. > > Signed-off-by: Amit Shah <[EMAIL PROTECTED]> > --- > Makefile | 10 +- > irqhook/Kbuild|3 + > irqhook/Makefile | 25 ++ > irqhook/irqhook_main.c| 215 ++ > kernel/Makefile |2 + > libkvm/libkvm-x86.c |9 +- > libkvm/libkvm.h | 16 + > qemu/Makefile.target |1 + > qemu/hw/apic.c|4 + > qemu/hw/isa.h |2 + > qemu/hw/pc.c |4 + > qemu/hw/pci-passthrough.c | 704 > + > qemu/hw/pci-passthrough.h | 119 qemu/hw/pci.c > | 13 + qemu/hw/pci.h |1 + > qemu/hw/piix_pci.c| 19 ++ > qemu/vl.c | 16 + > tools/pci_barsize.c | 53 > tools/pci_mmio.c | 82 ++ > 19 files changed, 1293 insertions(+), 5 deletions(-) > create mode 100644 irqhook/Kbuild > create mode 100644 irqhook/Makefile > create mode 100644 irqhook/irqhook_main.c > create mode 100644 qemu/hw/pci-passthrough.c > create mode 100644 qemu/hw/pci-passthrough.h > create mode 100644 tools/pci_barsize.c > create mode 100644 tools/pci_mmio.c > > diff --git a/Makefile b/Makefile > index 48a8dff..d4246fd 100644 > --- a/Makefile > +++ b/Makefile > @@ -7,16 +7,16 @@ rpmrelease = devel > > sane-arch = $(subst i386,x86,$(subst x86_64,x86,$(ARCH))) > > -.PHONY: kernel user libkvm qemu bios vgabios extboot clean libfdt > +.PHONY: kernel irqhook user libkvm qemu bios vgabios extboot clean > libfdt > > all: libkvm qemu > ifneq '$(filter $(ARCH), x86_64 i386 ia64)' '' > -all: $(if $(WANT_MODULE), kernel) user > +all: $(if $(WANT_MODULE), kernel irqhook) user > endif > > kcmd = $(if $(WANT_MODULE),,@\#) > > -qemu kernel user libkvm: > +qemu kernel user irqhook libkvm: > $(MAKE) -C $@ > > qemu: libkvm > @@ -77,6 +77,7 @@ install-rpm: > > install: > $(kcmd)make -C kernel DESTDIR="$(DESTDIR)" install > + $(kcmd)make -C irqhook DESTDIR="$(DESTDIR)" install > make -C libkvm DESTDIR="$(DESTDIR)" install > make -C qemu DESTDIR="$(DESTDIR)" install > > @@ -97,6 +98,7 @@ srpm: > tar czf $(RPMTOPDIR)/SOURCES/user.tar.gz user > tar czf $(RPMTOPDIR)/SOURCES/libkvm.tar.gz libkvm > tar czf $(RPMTOPDIR)/SOURCES/kernel.tar.gz kernel > + tar czf $(RPMTOPDIR)/SOURCES/irqhook.tar.gz irqhook > tar czf $(RPMTOPDIR)/SOURCES/scripts.tar.gz scripts > tar czf $(RPMTOPDIR)/SOURCES/extboot.tar.gz extboot > cp Makefile configure kvm_stat $(RPMTOPDIR)/SOURCES > @@ -104,7 +106,7 @@ srpm: > $(RM) $(tmpspec) > > clean: > - for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \ > + for i in $(if $(WANT_MODULE), kernel irqhook) user libkvm qemu > libfdt; do \ make -C $$i clean; \ > done > > diff --git a/irqhook/Kbuild b/irqhook/Kbuild > new file mode 100644 > index 000..9af75a4 > --- /dev/null > +++ b/irqhook/Kbuild > @@ -0,0 +1,3 @@ > +EXTRA_CFLAGS := -I$(src)/include > +obj-m := irqhook.o > +irqhook-objs := irqhook_main.o > diff --git a/irqhook/Makefile b/irqhook/Makefile > new file mode 100644 > index 000..3b1d851 > --- /dev/null > +++ b/irqhook/Makefile > @@ -0,0 +1,25 @@ > +include ../config.mak > + > +KVERREL = $(patsubst /lib/modules/%/build,%,$(KERNELDIR)) > + > +DESTDIR= > + > +INSTALLDIR = $(patsubst %/build,%/extra,$(KERNELDIR)) > + > +rpmrelease = devel > + > +LINUX = ../linux-2.6 > + > +all:: > + $(MAKE) -C $(KERNELDIR) M=`pwd` "$$@" > + > +#sync: > +#rsync --exclude='*.mod.c' "$(LINUX)"/drivers/irqhook/*.[ch] . > + > +install: > + mkdir -p $(DESTDIR)/$(INSTALLDIR) > + cp *.ko $(DESTDIR)/$(INSTALLDIR) > + /sbin/depmod -a > + > +clean: > + $(MAKE) -C $(KERNELDIR) M=`pwd` $@ > diff --git a/irqhook/irqhook_main.c b/irqhook/irqhook_main.c > new file mode 100644 > index 000..0f93d17 > --- /de
