Re: xbmc as a guest
On 01/15/12 22:05, Ryar wrote: > Hi > > I'd like to install a few servers as kvm guests in my home network and > to keep host as minimal as possible I'm thinking to install xbmc as a > guest too > > 1. Is is feasible ? As I read xbmc heavily uses opengl and I'm not sure > what about sound > 2. Is it possible to redirect output from guest as main output - I mean > host is connected to tv thus interested in to see xbmc picture only XBMC really wants direct access to the video and sound devices. While it might be possible to do this via device pass-through, then I think XBMC is one of these installs where you really want it installed directly on the box and not in a virtual machine. If you don't want to install it directly, you may have a look at the XBMC live USB image instead. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PCI Passthrough, amd_iommu detach_device error when unbind PCIe-to-PCI bridge
Hello, I come to this problem when using PCI passthrough (AMD IOMMU), I need to passthrough a single PCI device which is behind PCIe-to-PCI bridge. PCI tree in this case; # lspci -t -v -[:00]-+-00.0 ATI Technologies Inc RD890 PCI to PCI bridge (external gfx0 port A) +-00.2 ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) +-09.0-[01]00.0 Intel Corporation 82574L Gigabit Network Connection +-0a.0-[02]00.0 Intel Corporation 82574L Gigabit Network Connection +-11.0 ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] +-12.0 ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller +-12.1 ATI Technologies Inc SB7x0 USB OHCI1 Controller +-12.2 ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller +-13.0 ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Controller +-13.1 ATI Technologies Inc SB7x0 USB OHCI1 Controller +-13.2 ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Controller +-14.0 ATI Technologies Inc SBx00 SMBus Controller +-14.3 ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host controller +-14.4-[03]--+-03.0 Creative Labs SB Audigy |+-03.1 Creative Labs SB Audigy Game Port |+-03.2 Creative Labs SB Audigy FireWire Port |\-04.0 Matrox Graphics, Inc. MGA G200eW WPCM450 +-14.5 ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI2 Controller +-18.0 Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration +-18.1 Advanced Micro Devices [AMD] Family 10h Processor Address Map +-18.2 Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller +-18.3 Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control \-18.4 Advanced Micro Devices [AMD] Family 10h Processor Link Control I am passing-through only "03.0 Creative Labs SB Audigy" device which is just enough for the case, but to be able to do so i need to unbind all devices sharing the same bridge, as well as the bridge device itself before starting KVM guest; # echo 1002 4384 > /sys/bus/pci/drivers/pci-stub/new_id # echo :00:14.4 > /sys/bus/pci/drivers/pci-stub/unbind The actual passthrough works very good at guest side, but there is a problem when i shut the guest down; Jan 14 03:29:33 H8SCM kernel: [ 1413.439703] [ cut here ] Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] kernel BUG at /build/buildd/linux-3.2.0/drivers/iommu/amd_iommu.c:1740! Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] invalid opcode: [#1] SMP Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] CPU 0 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] Modules linked in: pci_stub ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables kvm_amd kvm vesafb w83795 jc42 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul bridge stp snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm snd_page_alloc snd_util_mem snd_hwdep snd_seq_midi snd_rawmidi snd_seq_midi_event psmouse snd_seq joydev snd_timer snd_seq_device usbhid serio_raw snd emu10k1_gp amd64_edac_mod gameport soundcore edac_core k10temp edac_mce_amd hid sp5100_tco i2c_piix4 ipmi_si ipmi_msghandler lp parport firewire_ohci firewire_core crc_itu_t e1000e Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] Pid: 1550, comm: kvm Not tainted 3.2.0-7-generic #13-Ubuntu Supermicro H8SCM/H8SCM Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] RIP: 0010:[] [] __detach_device+0xc6/0xd0 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] RSP: 0018:88020ea57ac8 EFLAGS: 00010046 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] RAX: dead00100100 RBX: 8802103dd640 RCX: fff0 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] RDX: 88020ea57a68 RSI: 0082 RDI: 8802103dd640 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] RBP: 88020ea57ae8 R08: 2000 R09: dead00100100 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] R10: dead00200200 R11: R12: Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] R13: dead00100100 R14: 8802103dd640 R15: 88020d634410 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] FS: 7fb8d2b9b700() GS:88021fc0() knlGS: Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] CS: 0010 DS: ES: CR0: 8005003b Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] CR2: 00d03000 CR3: 00020fe51000 CR4: 06f0 Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] DR0: DR1: DR2: Jan 14 03:29:33 H8SCM kernel: [ 1413.440001] DR3: DR6: 0ff0 D
Re: Device pass-through
I still poke at this when I get time.
I notice that pci_update_mappings calls pci_bar_address, and the latter
will always return PCI_BAR_UNMAPPED for this device. For the emulated
devices, pci_bar_address will get an address with PCI_ROM_ADDRESS_ENABLE
at some point, and pci_map_option_rom will be called. With the card
that I'm passing in, that never happens. Could anyone point me in the
direction I should go from here? What sets that bit for the emulated
devices that might not happen for the PCI card?
if (type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
new_addr = pci_get_quad(d->config + bar);
} else {
new_addr = pci_get_long(d->config + bar);
}
/* the ROM slot has a specific enable bit */
if (reg == PCI_ROM_SLOT && !(new_addr & PCI_ROM_ADDRESS_ENABLE)) {
return PCI_BAR_UNMAPPED;
}
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
xbmc as a guest
Hi I'd like to install a few servers as kvm guests in my home network and to keep host as minimal as possible I'm thinking to install xbmc as a guest too 1. Is is feasible ? As I read xbmc heavily uses opengl and I'm not sure what about sound 2. Is it possible to redirect output from guest as main output - I mean host is connected to tv thus interested in to see xbmc picture only BR ryar -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] KVM guest-kernel panics double fault
Thank you for applying this, Marcelo. I fear we (or me after I agreed) did some mistake by erasing the additional cpuid 0x8001 checks. In contradiction to only AMD it MUST also apply on Intel-CPUs. Documentation "http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-software-developer-manual-325462.pdf"; Vol. 2A 3-207 (PDF-page 811) first block of table. (in addition AMD's doku "http://support.amd.com/us/Processor_TechDocs/APM_V3_24594.pdf"; page 376 (PDF-page 408) table "Exceptions" on the bottom) Not all CPUs might have a syscall op at all (even in longmode) - they informing about that via cpuid (But MSR_EFER may be still set). (You can force it externally in qemu-kvm-emulation via "-cpu host,-syscall" ...) So an (guest) operating-system might not install *STAR-registers and crash again on such vcpus, right? I'll prepare some patch, asap. So everybody can judge this... regards, Stephan On 01/13/12 11:13, Marcelo Tosatti wrote: > On Thu, Jan 12, 2012 at 04:56:33PM +0100, Jan Kiszka wrote: >>> Stephan Baerwolf (2): >>> KVM: extend "struct x86_emulate_ops" with "get_cpuid" >>> KVM: fix missing "illegal instruction"-trap in protected modes >>> >>> arch/x86/include/asm/kvm_emulate.h | 19 >>> arch/x86/kvm/emulate.c | 80 >>> ++- >>> arch/x86/kvm/x86.c | 21 + >>> 3 files changed, 117 insertions(+), 3 deletions(-) >>> >> linux/scripts/checkpatch.pl can help identifying remaining style violations. >> >> Moreover, when sending your patches via Thunderbird, you first need to >> make sure that you have its line wrapping under control. "Toggle Word >> Wrap" helps me for single patches. But for series, I prefer (scripted) >> git format-patch/send-email. > Applied a cleanup up version of these patches. Thanks Stephan. > > http://git.kernel.org/?p=virt/kvm/kvm.git;a=commit;h=0769c5de24621141c953fbe1f943582d37cb4244 > > http://git.kernel.org/?p=virt/kvm/kvm.git;a=commit;h=e28ba7bb020f07193bc000453c8775e9d2c0dda7 > > > -- Dipl.-Inf. Stephan Bärwolf Ilmenau University of Technology, Integrated Communication Systems Group Phone: +49 (0)3677 69 4130 Email: stephan.baerw...@tu-ilmenau.de, Web: http://www.tu-ilmenau.de/iks -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] kvm: flush the dirty log when unregistering a slot
On 01/15/2012 04:40 PM, Gerhard Wiesinger wrote: > On Sun, 15 Jan 2012, Jan Kiszka wrote: > >> On 2012-01-15 15:17, Avi Kivity wrote: >>> Otherwise, the dirty log information is lost in the kernel forever. >>> >>> Fixes opensuse-12.1 boot screen, which changes the vga windows rapidly. >> >> Confirmed, problems solved here. > > Problem from: http://permalink.gmane.org/gmane.comp.emulators.qemu/131853 > > Confirmed to be fixed, too. Long awaited patch :-) Sorry, I forgot about that. Please ping me if I do that. > > BTW: There is also a major difference in video performance: > 1.) With Patch: 1400MB/s (MByte/s) > 2.) Without Patch: 6MB/s > > Any reason for that? What are you measuring exactly? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Fix MOVSX emulation
Ok. I will include MOVSXD as well in the future patch. Regards, Nadav On Sun, Jan 15, 2012 at 11:56 AM, Avi Kivity wrote: > On 01/14/2012 08:34 PM, Nadav Amit wrote: >> The destination register of MOVSX should be decoded similarily to MOVZX. >> >> Signed-off-by: Nadav Amit >> --- >> arch/x86/kvm/emulate.c | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c >> index 05a562b..7644a83 100644 >> --- a/arch/x86/kvm/emulate.c >> +++ b/arch/x86/kvm/emulate.c >> @@ -3553,7 +3553,8 @@ static int decode_operand(struct x86_emulate_ctxt >> *ctxt, struct operand *op, >> case OpReg: >> decode_register_operand(ctxt, op, >> op == &ctxt->dst && >> - ctxt->twobyte && (ctxt->b == 0xb6 || ctxt->b == >> 0xb7)); >> + ctxt->twobyte && ((ctxt->b & 0xfe) == 0xb6 || >> + (ctxt->b & 0xfe) == 0xbe)); >> break; >> case OpImmUByte: >> rc = decode_imm(ctxt, op, 1, false); > > Please post a unit test for this. See > git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git x86/emulate.c. > > -- > error compiling committee.c: too many arguments to function > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] kvm: flush the dirty log when unregistering a slot
On Sun, 15 Jan 2012, Jan Kiszka wrote: On 2012-01-15 15:17, Avi Kivity wrote: Otherwise, the dirty log information is lost in the kernel forever. Fixes opensuse-12.1 boot screen, which changes the vga windows rapidly. Confirmed, problems solved here. Problem from: http://permalink.gmane.org/gmane.comp.emulators.qemu/131853 Confirmed to be fixed, too. Long awaited patch :-) BTW: There is also a major difference in video performance: 1.) With Patch: 1400MB/s (MByte/s) 2.) Without Patch: 6MB/s Any reason for that? Ciao, Gerhard -- http://www.wiesinger.com/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 2012-01-15 15:29, Gleb Natapov wrote: > On Sun, Jan 15, 2012 at 03:21:45PM +0100, Jan Kiszka wrote: >> On 2012-01-15 14:39, Avi Kivity wrote: >>> On 01/15/2012 03:27 PM, Michael Tokarev wrote: On 15.01.2012 17:18, Avi Kivity wrote: > On 01/15/2012 03:10 PM, Michael Tokarev wrote: [] >> FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because >> of lack of boot support from scsi (and no alternative), and because >> many people's scripts who used boot= broke. I thought it is better >> to let users to have a chance to perform a smoother transition than >> to break their stuff. > > It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will > feature virtio-scsi, though of course that doesn't help already > installed guests or non Windows/Linux guests. Do you know what the use > cases requiring scsi boot are? I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447 and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance. >>> >>> Well we don't want to break people's guests. If the fix Gleb alluded to >>> doesn't work, we'll have to restore extboot or something similar. Let >>> us know. >> >> I would vote for proper seabios support or a free option rom. That would >> allow us to make progress with obsoleting qemu-kvm instead of making a >> step back again. >> > It is not enough to vote, somebody has to send patches :) And it seams > there are two kind of people: those who can make such a patch, but don't > because they know enough to avoid qemu lsi emulation and those who can't > make it and use lsi qemu emulation. I'm pretty sure there is also a set of people who need to use LSI and can write the proper support. Jan signature.asc Description: OpenPGP digital signature
Re: qemu-kvm: Inconsistent vgabios reference
On Sun, Jan 15, 2012 at 03:21:45PM +0100, Jan Kiszka wrote: > On 2012-01-15 14:39, Avi Kivity wrote: > > On 01/15/2012 03:27 PM, Michael Tokarev wrote: > >> On 15.01.2012 17:18, Avi Kivity wrote: > >>> On 01/15/2012 03:10 PM, Michael Tokarev wrote: > >> [] > FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because > of lack of boot support from scsi (and no alternative), and because > many people's scripts who used boot= broke. I thought it is better > to let users to have a chance to perform a smoother transition than > to break their stuff. > >>> > >>> It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will > >>> feature virtio-scsi, though of course that doesn't help already > >>> installed guests or non Windows/Linux guests. Do you know what the use > >>> cases requiring scsi boot are? > >> > >> I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447 > >> and a few private messages asking me for ways to restore booting from scsi, > >> all talking about older/custom systems which worked for years in kvm. > >> As you can see in the bugreport mentioned, I know that scsi is broken > >> and should not be used and so on, and suggested switching from it on > >> every chance. > > > > Well we don't want to break people's guests. If the fix Gleb alluded to > > doesn't work, we'll have to restore extboot or something similar. Let > > us know. > > I would vote for proper seabios support or a free option rom. That would > allow us to make progress with obsoleting qemu-kvm instead of making a > step back again. > It is not enough to vote, somebody has to send patches :) And it seams there are two kind of people: those who can make such a patch, but don't because they know enough to avoid qemu lsi emulation and those who can't make it and use lsi qemu emulation. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: flush the dirty log when unregistering a slot
On 2012-01-15 15:17, Avi Kivity wrote:
> Otherwise, the dirty log information is lost in the kernel forever.
>
> Fixes opensuse-12.1 boot screen, which changes the vga windows rapidly.
Confirmed, problems solved here.
Thanks,
Jan
>
> Signed-off-by: Avi Kivity
> ---
>
> This patch gives me a deja vu - I'm sure I've fixed exactly the same issue
> before.
>
> Please test.
>
> kvm-all.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 3174f42..2cc4562 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -566,6 +566,10 @@ static void kvm_set_phys_mem(MemoryRegionSection
> *section, bool add)
>
> old = *mem;
>
> +if (mem->flags & KVM_MEM_LOG_DIRTY_PAGES) {
> +kvm_physical_sync_dirty_bitmap(section);
> +}
> +
> /* unregister the overlapping slot */
> mem->memory_size = 0;
> err = kvm_set_user_memory_region(s, mem);
> -- 1.7.7.1
>
signature.asc
Description: OpenPGP digital signature
Re: qemu-kvm: Inconsistent vgabios reference
On 2012-01-15 14:39, Avi Kivity wrote: > On 01/15/2012 03:27 PM, Michael Tokarev wrote: >> On 15.01.2012 17:18, Avi Kivity wrote: >>> On 01/15/2012 03:10 PM, Michael Tokarev wrote: >> [] FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff. >>> >>> It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will >>> feature virtio-scsi, though of course that doesn't help already >>> installed guests or non Windows/Linux guests. Do you know what the use >>> cases requiring scsi boot are? >> >> I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447 >> and a few private messages asking me for ways to restore booting from scsi, >> all talking about older/custom systems which worked for years in kvm. >> As you can see in the bugreport mentioned, I know that scsi is broken >> and should not be used and so on, and suggested switching from it on >> every chance. > > Well we don't want to break people's guests. If the fix Gleb alluded to > doesn't work, we'll have to restore extboot or something similar. Let > us know. I would vote for proper seabios support or a free option rom. That would allow us to make progress with obsoleting qemu-kvm instead of making a step back again. Jan signature.asc Description: OpenPGP digital signature
[PATCH] qemu-kvm: Remove kvm subdirectory
Nothing useful remaining there. Signed-off-by: Jan Kiszka --- kvm/.gitignore | 66 - kvm/Makefile| 125 -- kvm/configure | 142 -- kvm/extboot/Makefile| 41 - kvm/extboot/STATUS |6 - kvm/extboot/signrom.c | 79 - kvm/include/ia64/asm/kvm.h | 264 --- kvm/include/ia64/asm/kvm_para.h | 31 - kvm/include/linux/compiler.h|2 - kvm/include/linux/config.h | 43 - kvm/include/linux/kvm.h | 784 --- kvm/include/linux/kvm_para.h| 41 - kvm/include/linux/vhost.h | 130 -- kvm/include/powerpc/asm/kvm.h | 62 - kvm/include/powerpc/asm/kvm_para.h | 37 - kvm/include/x86/asm/kvm.h | 324 --- kvm/include/x86/asm/kvm_para.h | 149 -- kvm/kvm.spec| 139 -- kvm/kvm_stat| 469 - kvm/libfdt/Makefile | 19 - kvm/libfdt/README |3 - kvm/libfdt/fdt.c| 194 -- kvm/libfdt/fdt.h| 60 - kvm/libfdt/fdt_ro.c | 476 - kvm/libfdt/fdt_rw.c | 467 - kvm/libfdt/fdt_strerror.c | 96 - kvm/libfdt/fdt_sw.c | 258 --- kvm/libfdt/fdt_wip.c| 144 -- kvm/libfdt/libfdt.h | 1076 -- kvm/libfdt/libfdt_env.h | 22 - kvm/libfdt/libfdt_internal.h| 96 - kvm/libkvm/Makefile | 54 - kvm/libkvm/config-i386.mak |6 - kvm/libkvm/config-ia64.mak |5 - kvm/libkvm/config-ppc.mak |4 - kvm/libkvm/config-s390.mak |3 - kvm/libkvm/config-s390x.mak |3 - kvm/libkvm/config-x86_64.mak|6 - kvm/libkvm/kvm-common.h | 94 - kvm/libkvm/kvm-ia64.h | 31 - kvm/libkvm/kvm-powerpc.h| 36 - kvm/libkvm/kvm-s390.h | 31 - kvm/libkvm/kvm-x86.h| 55 - kvm/libkvm/libkvm-ia64.c| 82 - kvm/libkvm/libkvm-powerpc.c | 100 - kvm/libkvm/libkvm-s390.c| 110 - kvm/libkvm/libkvm-x86.c | 637 -- kvm/libkvm/libkvm.c | 1497 -- kvm/libkvm/libkvm.h | 838 kvm/scripts/65-kvm.rules|1 - kvm/scripts/kvm | 226 -- kvm/scripts/make-combined-release | 36 - kvm/scripts/mkbootdisk | 30 - kvm/scripts/qemu-ifup |5 - kvm/scripts/run_img |4 - kvm/scripts/vmxcap | 216 -- kvm/vgabios/.cvsignore |1 - kvm/vgabios/BUGS|3 - kvm/vgabios/COPYING | 504 - kvm/vgabios/ChangeLog | 1264 kvm/vgabios/Makefile| 87 - kvm/vgabios/Notes | 11 - kvm/vgabios/README | 219 -- kvm/vgabios/TODO| 26 - kvm/vgabios/biossums.c | 282 --- kvm/vgabios/clext.c | 1688 --- kvm/vgabios/dataseghack | 23 - kvm/vgabios/tests/lfbprof/Makefile |5 - kvm/vgabios/tests/lfbprof/lfbprof.c | 594 -- kvm/vgabios/tests/lfbprof/lfbprof.h | 149 -- kvm/vgabios/tests/testbios.c| 353 kvm/vgabios/vbe.c | 1432 - kvm/vgabios/vbe.h | 313 --- kvm/vgabios/vbe_display_api.txt | 237 --- kvm/vgabios/vbetables-gen.c | 264 --- kvm/vgabios/vgabios.c | 3853 --- kvm/vgabios/vgabios.h | 47 - kvm/vgabios/vgafonts.h | 784 --- kvm/vgabios/vgatables.h | 622 -- 79 files changed, 0 insertions(+), 22716 deletions(-) delete mode 100644 kvm/.gitignore delete mode 100644 kvm/Makefile delete mode 100755 kvm/configure delete mode 100644 kvm/extboot/Makefile delete mode 100644 kvm/extboot/STATUS delete mode 100644 kvm/extboot/signrom.c delete mode 100644 kvm/include/ia64/asm/kvm.h delete mode 100644 kvm/include/ia64/asm/kvm_para.h delete mode 100644 kvm/include/linux/compiler.h delete mode 100644 kvm/include/linux/config.h delete mode 100644 kvm/include/linux/kvm.h delete mode 100644 kvm/include/linux/kvm_para.h delete mode 100644 kvm/include/linux/vhost.h delete mode 100644 kvm/include/powerpc/asm/kvm.h delete mode 100644 kvm/include/powerpc/asm/kvm_para.h delete mode 100644 kvm/include/x86/asm/kvm.h delete mode 100644 kvm/include/x86/asm/kvm_para.h delete mode 100644 kvm/kvm.spec delete mode 100755 kvm/kvm_stat delete mode 100644 kvm/libfdt/Makefile delete mode 100644 kvm/libfdt/README delete mode 100644 kvm/libfdt/fdt.c delete mode 100644 kvm/libfdt/fdt.h delete mode 100644 kvm/libfdt/fdt_ro.c delete mode 100644 kvm/libfdt/fdt_rw.c delete mode 1006
[PATCH] kvm: flush the dirty log when unregistering a slot
Otherwise, the dirty log information is lost in the kernel forever.
Fixes opensuse-12.1 boot screen, which changes the vga windows rapidly.
Signed-off-by: Avi Kivity
---
This patch gives me a deja vu - I'm sure I've fixed exactly the same issue
before.
Please test.
kvm-all.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 3174f42..2cc4562 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -566,6 +566,10 @@ static void kvm_set_phys_mem(MemoryRegionSection *section,
bool add)
old = *mem;
+if (mem->flags & KVM_MEM_LOG_DIRTY_PAGES) {
+kvm_physical_sync_dirty_bitmap(section);
+}
+
/* unregister the overlapping slot */
mem->memory_size = 0;
err = kvm_set_user_memory_region(s, mem);
--
1.7.7.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: MMU: increment stats after event occurrence
On 01/13/2012 02:56 PM, Davidlohr Bueso wrote: > On Fri, 2012-01-13 at 10:24 +0900, Takuya Yoshikawa wrote: > > (2012/01/13 10:08), Davidlohr Bueso wrote: > > > From: Davidlohr Bueso > > > > > > It makes more sense to actually increment statistics for tlb flushes and > > > page table entry updates after such _events_ occur, instead of before. > > > > Why? > > > From a logical point of view its better to increase stats once the event > is processed - usually because it can fail and therefore the stats would > be incorrect. > That doesn't hold for the cases you change. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 01/15/2012 03:27 PM, Michael Tokarev wrote: > On 15.01.2012 17:18, Avi Kivity wrote: > > On 01/15/2012 03:10 PM, Michael Tokarev wrote: > [] > >> FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because > >> of lack of boot support from scsi (and no alternative), and because > >> many people's scripts who used boot= broke. I thought it is better > >> to let users to have a chance to perform a smoother transition than > >> to break their stuff. > > > > It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will > > feature virtio-scsi, though of course that doesn't help already > > installed guests or non Windows/Linux guests. Do you know what the use > > cases requiring scsi boot are? > > I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447 > and a few private messages asking me for ways to restore booting from scsi, > all talking about older/custom systems which worked for years in kvm. > As you can see in the bugreport mentioned, I know that scsi is broken > and should not be used and so on, and suggested switching from it on > every chance. Well we don't want to break people's guests. If the fix Gleb alluded to doesn't work, we'll have to restore extboot or something similar. Let us know. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vhost-net: add module alias (v2.1)
On Thu, Jan 12, 2012 at 08:07:01PM -0800, David Miller wrote: > From: Stephen Hemminger > Date: Wed, 11 Jan 2012 21:30:38 -0800 > > > Subject: vhost-net: add module alias (v2.1) > > > > By adding some module aliases, programs (or users) won't have to explicitly > > call modprobe. Vhost-net will always be available if built into the kernel. > > It does require assigning a permanent minor number for depmod to work. > > > > Also: > > - use C99 style initialization. > > - add missing entry in documentation for loop-control > > > > Signed-off-by: Stephen Hemminger > > ACKs, NACKs? What is happening here? I would like an Ack from Alan Cox who switched vhost-net to a dynamic minor in the first place, in commit 79907d89c397b8bc2e05b347ec94e928ea919d33. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7] kvm: make vcpu life cycle separated from kvm instance
On 01/15/2012 03:17 PM, Liu ping fan wrote:
> On Thu, Jan 12, 2012 at 8:37 PM, Avi Kivity wrote:
> > On 01/07/2012 04:55 AM, Liu Ping Fan wrote:
> >> From: Liu Ping Fan
> >>
> >> Currently, vcpu will be destructed only after kvm instance is
> >> destroyed. This result to vcpu keep idle in kernel, but can not
> >> be freed when it is unplugged in guest.
> >>
> >> Change this to vcpu's destruction before kvm instance, so vcpu MUST
> >
> > Must?
> >
> Yes, in kvm_arch_vcpu_destruct-->kvm_put_kvm(kvm); so after all vcpu
> destroyed, then can kvm instance
Oh. Words like MUST imply that the user has to do something different.
It's just that the normal order of operations changes.
> >> and CAN be destroyed before kvm instance. By this way, we can remove
> >> vcpu when guest does not need it any longer.
> >>
> >> TODO: push changes to other archs besides x86.
> >>
> >> -Rename kvm_vcpu_zap to kvm_vcpu_destruct and so on.
> >
> > kvm_vcpu_destroy.
> >
> The name "kvm_arch_vcpu_destroy" is already occupied in different arch.
It's actually in all archs. But having both kvm_arch_vcpu_destroy() and
kvm_arch_vcpu_destruct() isn't going to make the code more
understandable, need to merge the two, or find different names.
> So change
> kvm_vcpu_zap -> kvm_vcpu_destruct
> kvm_vcpu_arch_zap -> kvm_vcpu_arch_destruct
> >> - struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
> >> + struct list_head vcpus;
> >
> > This has the potential for a slight performance regression by bouncing
> > an extra cache line, but it's acceptable IMO. We can always introduce
>
> Sorry, not clear about this scene, do you mean that the changing of
> vcpu link list will cause the invalid of cache between SMP? But the
> link list is not changed often.
No, I mean that kvm_for_each_vcpu() now has to bounce a cacheline for
each vcpu, in order to read the link.
> >> + kvm_for_each_vcpu(vcpu, kvm) {
> >> + if (kvm->last_boosted_vcpu_id < 0 && !pass) {
> >> + pass = 1;
> >> + break;
> >> + }
> >> + if (!pass && !firststart &&
> >> + vcpu->vcpu_id != kvm->last_boosted_vcpu_id) {
> >> + continue;
> >> + } else if (!pass && !firststart) {
> >> + firststart = 1;
> >> continue;
> >> - } else if (pass && i > last_boosted_vcpu)
> >> + } else if (pass && !lastone) {
> >> + if (vcpu->vcpu_id ==
> >> kvm->last_boosted_vcpu_id)
> >> + lastone = 1;
> >> + } else if (pass && lastone)
> >> break;
> >> +
> >
> > Seems like a large change. Is this because the vcpu list is unordered?
> > Maybe it's better to order it.
> >
> To find the last boosted vcpu (I guest it is more likely the lock
> holder), we must enumerate the vcpu link list. While implemented by
> kvm->vcpus[], it is more facile.
Please simplify this code, it's pretty complicated.
> >> +
> >> if (yield_to(task, 1)) {
> >> put_task_struct(task);
> >> - kvm->last_boosted_vcpu = i;
> >> + mutex_lock(&kvm->lock);
> >> + kvm->last_boosted_vcpu_id = vcpu->vcpu_id;
> >> + mutex_unlock(&kvm->lock);
> >
> > Why take the mutex?
> >
> In kvm_vcpu_release()
>mutex_lock(&kvm->lock);
>if (kvm->last_boosted_vcpu_id == vcpu->vcpu_id)
>
> ->CAN NOT break
>kvm->last_boosted_vcpu_id = -1;
>mutex_unlock(&kvm->lock);
It's not pretty taking a vm-wide lock here. Just make the code
resilient to incorrect vcpu_id. If it doesn't find
last_boosted_vcpu_id, it should just pick something, like the first or
last vcpu in the list.
>
> >> static int kvm_vcpu_release(struct inode *inode, struct file *filp)
> >> {
> >> struct kvm_vcpu *vcpu = filp->private_data;
> >> + struct kvm *kvm = vcpu->kvm;
> >> + filp->private_data = NULL;
> >> +
> >> + mutex_lock(&kvm->lock);
> >> + list_del_rcu(&vcpu->list);
> >> + atomic_dec(&kvm->online_vcpus);
> >> + mutex_unlock(&kvm->lock);
> >> + synchronize_srcu_expedited(&kvm->srcu);
> >
> > Why _expedited?
> >
> > Even better would be call_srcu() but it doesn't exist.
> >
> > I think we can actually use regular rcu. The only user that blocks is
> > kvm_vcpu_on_spin(), yes? so we can convert the vcpu to a task using
> > get_pid_task(), then, outside the rcu lock, call yield_to().
> >
> Yes, kvm_vcpu_on_spin() is the only one. But I think if outside the
> rcu lock, call yield_to(), it will be like the following
>
> again:
> rcu_lock()
> kvm_for_each_vcpu(){
> ..
> }
> rcu_unlock()
>
Re: qemu-kvm: Inconsistent vgabios reference
On Sun, Jan 15, 2012 at 05:27:39PM +0400, Michael Tokarev wrote: > On 15.01.2012 17:18, Avi Kivity wrote: > > On 01/15/2012 03:10 PM, Michael Tokarev wrote: > [] > >> FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because > >> of lack of boot support from scsi (and no alternative), and because > >> many people's scripts who used boot= broke. I thought it is better > >> to let users to have a chance to perform a smoother transition than > >> to break their stuff. > > > > It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will > > feature virtio-scsi, though of course that doesn't help already > > installed guests or non Windows/Linux guests. Do you know what the use > > cases requiring scsi boot are? > > I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447 > and a few private messages asking me for ways to restore booting from scsi, > all talking about older/custom systems which worked for years in kvm. > As you can see in the bugreport mentioned, I know that scsi is broken > and should not be used and so on, and suggested switching from it on > every chance. > > >> Now, I've a question: what seabios implementation of extboot we're > >> talking about? -option-rom which is impossible to select as a first > >> boot device? > > > > seabios has native support for booting from virtio-blk, and will > > natively support virtio-scsi as well. > > Ah. Well, I thought especially about lsi emulated scsi. I wasn't > able to boot from it even with their bios -- once there's at least > one other bootable device present (including the NIC) it refuses > to boot from lsi emulated scsi drive. > Kevin is going to include a patch to Seabios to fix that. Meanwhile you can use bootindex to specify boot order. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 15.01.2012 17:18, Avi Kivity wrote: > On 01/15/2012 03:10 PM, Michael Tokarev wrote: [] >> FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because >> of lack of boot support from scsi (and no alternative), and because >> many people's scripts who used boot= broke. I thought it is better >> to let users to have a chance to perform a smoother transition than >> to break their stuff. > > It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will > feature virtio-scsi, though of course that doesn't help already > installed guests or non Windows/Linux guests. Do you know what the use > cases requiring scsi boot are? I've one (not very pleasant) bugreport handy, http://bugs.debian.org/652447 and a few private messages asking me for ways to restore booting from scsi, all talking about older/custom systems which worked for years in kvm. As you can see in the bugreport mentioned, I know that scsi is broken and should not be used and so on, and suggested switching from it on every chance. >> Now, I've a question: what seabios implementation of extboot we're >> talking about? -option-rom which is impossible to select as a first >> boot device? > > seabios has native support for booting from virtio-blk, and will > natively support virtio-scsi as well. Ah. Well, I thought especially about lsi emulated scsi. I wasn't able to boot from it even with their bios -- once there's at least one other bootable device present (including the NIC) it refuses to boot from lsi emulated scsi drive. Thanks, /mjt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/2] kvm: set affinity hint for assigned device msi
On Thu, Jan 12, 2012 at 04:09:17PM +0200, Avi Kivity wrote:
> On 10/11/2011 08:38 PM, Michael S. Tsirkin wrote:
> > To forward an interrupt to a vcpu that runs on
> > a host cpu different from the current one,
> > we need an ipi which likely will cost us as much
> > as delivering the interrupt directly to that cpu would.
> >
> > Set irq affinity hint to point there, irq balancer
> > can then take this into accound and balance
> > interrupts accordingly.
> >
> >
> > +static void kvm_vcpu_host_irq_hint(struct kvm_vcpu *vcpu, int host_irq)
> > +{
> > + const struct cpumask *mask;
> > + /* raw_smp_processor_id() is ok here: if we get preempted we can get a
> > +* wrong value but we don't mind much. */
> > + if (host_irq >= 0 && unlikely(vcpu->cpu != raw_smp_processor_id())) {
> > + mask = get_cpu_mask(vcpu->cpu);
> > + irq_set_affinity_hint(host_irq, mask);
> > + }
> > +}
> > +
> > int kvm_irq_delivery_to_apic(struct kvm *kvm, struct kvm_lapic *src,
> > struct kvm_lapic_irq *irq, int host_irq)
> > {
> > @@ -102,6 +114,7 @@ int kvm_irq_delivery_to_apic(struct kvm *kvm, struct
> > kvm_lapic *src,
> > if (r < 0)
> > r = 0;
> > r += kvm_apic_set_irq(vcpu, irq);
> > + kvm_vcpu_host_irq_hint(vcpu, host_irq);
>
> Doing this every time seems excessive.
Please note this doesn't modify the mapping in the hardware:
it only updates the hint for the irqbalancer,
and only if we target a CPU which is different
from the current one.
> How about doing it every N interrupts?
That's certainly easy.
> We can even collect information about which vcpus were
> targeted, and then use a mask instead of just one vcpu.
Yes, we can, but it certainly becomes much more complex.
The motivatin behind using the same host cpu is reducing the
number of IPIs. If the interrupt is bouncing between
guest VCPUs, this optimizaion won't work, so what's the
theory behind using a mask?
How about detecting an unstable vcpu mapping and
completely disabling the optimization, instead?
> --
> error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 01/15/2012 03:10 PM, Michael Tokarev wrote: > On 15.01.2012 16:53, Avi Kivity wrote: > > On 01/15/2012 02:50 PM, Jan Kiszka wrote: > [] > >> extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad > > > > Yeah, but it isn't history for people running older qemu-kvm's. We > > don't need extboot itself, but we do need to keep the boot option (as > > 2a06 does). The question is do we need to preserve its meaning too > > (with the seabios implementation instead of extboot's). > > FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because > of lack of boot support from scsi (and no alternative), and because > many people's scripts who used boot= broke. I thought it is better > to let users to have a chance to perform a smoother transition than > to break their stuff. It's really sad that people have to use lsi scsi. Luckily qemu 1.1 will feature virtio-scsi, though of course that doesn't help already installed guests or non Windows/Linux guests. Do you know what the use cases requiring scsi boot are? > Now, I've a question: what seabios implementation of extboot we're > talking about? -option-rom which is impossible to select as a first > boot device? seabios has native support for booting from virtio-blk, and will natively support virtio-scsi as well. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7] kvm: make vcpu life cycle separated from kvm instance
On Thu, Jan 12, 2012 at 8:37 PM, Avi Kivity wrote:
> On 01/07/2012 04:55 AM, Liu Ping Fan wrote:
>> From: Liu Ping Fan
>>
>> Currently, vcpu will be destructed only after kvm instance is
>> destroyed. This result to vcpu keep idle in kernel, but can not
>> be freed when it is unplugged in guest.
>>
>> Change this to vcpu's destruction before kvm instance, so vcpu MUST
>
> Must?
>
Yes, in kvm_arch_vcpu_destruct-->kvm_put_kvm(kvm); so after all vcpu
destroyed, then can kvm instance
>> and CAN be destroyed before kvm instance. By this way, we can remove
>> vcpu when guest does not need it any longer.
>>
>> TODO: push changes to other archs besides x86.
>>
>> -Rename kvm_vcpu_zap to kvm_vcpu_destruct and so on.
>
> kvm_vcpu_destroy.
>
The name "kvm_arch_vcpu_destroy" is already occupied in different arch.
So change
kvm_vcpu_zap -> kvm_vcpu_destruct
kvm_vcpu_arch_zap -> kvm_vcpu_arch_destruct
>>
>> struct kvm_vcpu {
>> struct kvm *kvm;
>> + struct list_head list;
>
> vcpu_list_link, so it's clear this is not a head but a link, and so we
> know which list it belongs to.
>
OK
>> - struct kvm_vcpu *vcpus[KVM_MAX_VCPUS];
>> + struct list_head vcpus;
>
> This has the potential for a slight performance regression by bouncing
> an extra cache line, but it's acceptable IMO. We can always introduce
Sorry, not clear about this scene, do you mean that the changing of
vcpu link list will cause the invalid of cache between SMP? But the
link list is not changed often.
> an apic ID -> vcpu hash table which improves things all around.
>
>> |
>> @@ -1593,11 +1598,9 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>> {
>> struct kvm *kvm = me->kvm;
>> struct kvm_vcpu *vcpu;
>> - int last_boosted_vcpu = me->kvm->last_boosted_vcpu;
>> - int yielded = 0;
>> - int pass;
>> - int i;
>> -
>> + struct task_struct *task = NULL;
>> + struct pid *pid;
>> + int pass, firststart, lastone, yielded, idx;
>
> Avoid unrelated changes please.
>
OK
>> @@ -1605,15 +1608,26 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>> * VCPU is holding the lock that we need and will release it.
>> * We approximate round-robin by starting at the last boosted VCPU.
>> */
>> - for (pass = 0; pass < 2 && !yielded; pass++) {
>> - kvm_for_each_vcpu(i, vcpu, kvm) {
>> - struct task_struct *task = NULL;
>> - struct pid *pid;
>> - if (!pass && i < last_boosted_vcpu) {
>> - i = last_boosted_vcpu;
>> + for (pass = 0, firststart = 0; pass < 2 && !yielded; pass++) {
>> +
>> + idx = srcu_read_lock(&kvm->srcu);
>
> Can move the lock to the top level.
>
OK
>> + kvm_for_each_vcpu(vcpu, kvm) {
>> + if (kvm->last_boosted_vcpu_id < 0 && !pass) {
>> + pass = 1;
>> + break;
>> + }
>> + if (!pass && !firststart &&
>> + vcpu->vcpu_id != kvm->last_boosted_vcpu_id) {
>> + continue;
>> + } else if (!pass && !firststart) {
>> + firststart = 1;
>> continue;
>> - } else if (pass && i > last_boosted_vcpu)
>> + } else if (pass && !lastone) {
>> + if (vcpu->vcpu_id == kvm->last_boosted_vcpu_id)
>> + lastone = 1;
>> + } else if (pass && lastone)
>> break;
>> +
>
> Seems like a large change. Is this because the vcpu list is unordered?
> Maybe it's better to order it.
>
To find the last boosted vcpu (I guest it is more likely the lock
holder), we must enumerate the vcpu link list. While implemented by
kvm->vcpus[], it is more facile.
> Rik?
>
>> if (vcpu == me)
>> continue;
>> if (waitqueue_active(&vcpu->wq))
>> @@ -1629,15 +1643,20 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>> put_task_struct(task);
>> continue;
>> }
>> +
>> if (yield_to(task, 1)) {
>> put_task_struct(task);
>> - kvm->last_boosted_vcpu = i;
>> + mutex_lock(&kvm->lock);
>> + kvm->last_boosted_vcpu_id = vcpu->vcpu_id;
>> + mutex_unlock(&kvm->lock);
>
> Why take the mutex?
>
In kvm_vcpu_release()
mutex_lock(&kvm->lock);
if (kvm->last_boosted_vcpu_id == vcpu->vcpu_id)
->CAN NOT break
kvm->last_boosted_vcpu_id = -1;
mutex_unlock(&kvm->lock);
>> @@ -1673,11 +1692,30 @@ static int kvm_vcpu_mmap(struct file *file, struct
>> vm_area_
[PATCH] kvm tools: Remove tags/TAGS on "make clean"
Signed-off-by: Cyrill Gorcunov --- tools/kvm/Makefile |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6.git/tools/kvm/Makefile === --- linux-2.6.git.orig/tools/kvm/Makefile +++ linux-2.6.git/tools/kvm/Makefile @@ -327,6 +327,8 @@ clean: $(Q) rm -rf tests/boot/rootfs/ $(Q) rm -f $(DEPS) $(OBJS) $(PROGRAM) $(PROGRAM_ALIAS) $(GUEST_INIT) $(GUEST_INIT_S2) $(Q) rm -f cscope.* + $(Q) rm -f tags + $(Q) rm -f TAGS $(Q) rm -f $(KVM_INCLUDE)/common-cmds.h $(Q) rm -f KVMTOOLS-VERSION-FILE .PHONY: clean -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 15.01.2012 16:53, Avi Kivity wrote: > On 01/15/2012 02:50 PM, Jan Kiszka wrote: [] >> extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad > > Yeah, but it isn't history for people running older qemu-kvm's. We > don't need extboot itself, but we do need to keep the boot option (as > 2a06 does). The question is do we need to preserve its meaning too > (with the seabios implementation instead of extboot's). FWIW, I had to patch extboot back in for debian qemu-kvm 1.0, because of lack of boot support from scsi (and no alternative), and because many people's scripts who used boot= broke. I thought it is better to let users to have a chance to perform a smoother transition than to break their stuff. Now, I've a question: what seabios implementation of extboot we're talking about? -option-rom which is impossible to select as a first boot device? Thanks, /mjt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 01/15/2012 02:55 PM, Jan Kiszka wrote: > > Yeah, but it isn't history for people running older qemu-kvm's. We > > don't need extboot itself, but we do need to keep the boot option (as > > 2a06 does). The question is do we need to preserve its meaning too > > (with the seabios implementation instead of extboot's). > > Possibly. But that is unrelated to any of the historic bits in kvm/. Right. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 2012-01-15 13:53, Avi Kivity wrote: > On 01/15/2012 02:50 PM, Jan Kiszka wrote: >> On 2012-01-15 13:49, Avi Kivity wrote: >>> On 01/15/2012 02:44 PM, Jan Kiszka wrote: OK, thanks. As that repos is now the vgabios reference, nothing valuable can be lost when we drop the kvm/ folder, right? >>> >>> I guess so. >>> >>> What about extboot w/ -M pc-0.foo? I guess we'll boot with a newer >>> seabios in any case, but we probably will have boot order issues. Maybe >>> we should make boot=on talk to the boot order code. >> >> extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad >> > > Yeah, but it isn't history for people running older qemu-kvm's. We > don't need extboot itself, but we do need to keep the boot option (as > 2a06 does). The question is do we need to preserve its meaning too > (with the seabios implementation instead of extboot's). Possibly. But that is unrelated to any of the historic bits in kvm/. Jan signature.asc Description: OpenPGP digital signature
[GIT PULL] kvm tools: Cleanups in various modules
Hi Pekka, Please pull cleanups which improve code and add uninitialization on guest termination to various modules. -- The following changes since commit 1cf7f482b481942fb533d83a56057a2b564bb057: kvm tools: Simply write_in_full() check semantics (2012-01-09 21:02:28 +0200) are available in the git repository at: git://github.com/sashalevin/linux-kvm.git cleanups Sasha Levin (12): kvm tools: Split kvm_cmd_run into init, work and exit kvm tools: Fixes for symbol resolving module kvm tools: Fixes for IRQ module kvm tools: Fixes for UI modules kvm tools: Fixes for ioport module kvm tools: Fixes for ioeventfd module kvm tools: Fixes for serial module kvm tools: Fixes for mptable module kvm tools: Fixes for PCI module kvm tools: Fixes for rtc module kvm tools: Fixes for disk image module kvm tools: Fixes for virtio module tools/kvm/builtin-run.c | 202 +-- tools/kvm/disk/blk.c| 13 ++- tools/kvm/disk/core.c | 76 +++- tools/kvm/disk/qcow.c |2 +- tools/kvm/disk/raw.c|9 +- tools/kvm/framebuffer.c |9 ++- tools/kvm/hw/pci-shmem.c|7 +- tools/kvm/hw/rtc.c | 27 - tools/kvm/hw/serial.c | 41 ++- tools/kvm/hw/vesa.c | 17 ++- tools/kvm/include/kvm/8250-serial.h |3 +- tools/kvm/include/kvm/disk-image.h |2 +- tools/kvm/include/kvm/framebuffer.h |1 + tools/kvm/include/kvm/ioeventfd.h |8 +- tools/kvm/include/kvm/ioport.h |5 +- tools/kvm/include/kvm/irq.h |3 +- tools/kvm/include/kvm/kvm.h |7 +- tools/kvm/include/kvm/pci.h |5 +- tools/kvm/include/kvm/rbtree-interval.h |1 + tools/kvm/include/kvm/rtc.h |5 +- tools/kvm/include/kvm/sdl.h |7 +- tools/kvm/include/kvm/symbol.h |7 +- tools/kvm/include/kvm/virtio-blk.h |5 +- tools/kvm/include/kvm/virtio-pci.h |1 + tools/kvm/include/kvm/virtio-rng.h |4 +- tools/kvm/include/kvm/virtio-trans.h|1 + tools/kvm/include/kvm/vnc.h | 10 ++- tools/kvm/ioeventfd.c | 158 +--- tools/kvm/ioport.c | 69 ++- tools/kvm/kvm.c | 99 ++- tools/kvm/mmio.c|8 +- tools/kvm/pci.c | 60 +++--- tools/kvm/powerpc/kvm.c |5 + tools/kvm/symbol.c | 57 +++-- tools/kvm/ui/sdl.c | 31 - tools/kvm/ui/vnc.c | 22 +++- tools/kvm/util/rbtree-interval.c| 11 +- tools/kvm/virtio/blk.c | 37 -- tools/kvm/virtio/pci.c | 46 ++- tools/kvm/virtio/rng.c | 27 +++- tools/kvm/virtio/trans.c|4 +- tools/kvm/x86/include/kvm/mptable.h |3 +- tools/kvm/x86/irq.c | 52 ++-- tools/kvm/x86/kvm-cpu.c | 10 +- tools/kvm/x86/kvm.c | 16 +++- tools/kvm/x86/mptable.c | 15 ++- 46 files changed, 917 insertions(+), 291 deletions(-) -- Sasha. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 01/15/2012 02:50 PM, Jan Kiszka wrote: > On 2012-01-15 13:49, Avi Kivity wrote: > > On 01/15/2012 02:44 PM, Jan Kiszka wrote: > >> OK, thanks. > >> > >> As that repos is now the vgabios reference, nothing valuable can be lost > >> when we drop the kvm/ folder, right? > >> > > > > I guess so. > > > > What about extboot w/ -M pc-0.foo? I guess we'll boot with a newer > > seabios in any case, but we probably will have boot order issues. Maybe > > we should make boot=on talk to the boot order code. > > extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad > Yeah, but it isn't history for people running older qemu-kvm's. We don't need extboot itself, but we do need to keep the boot option (as 2a06 does). The question is do we need to preserve its meaning too (with the seabios implementation instead of extboot's). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/23] kvm: convert to MemoryListener API
On 2012-01-15 13:50, Avi Kivity wrote: > On 01/15/2012 02:49 PM, Avi Kivity wrote: >> On 01/15/2012 02:40 PM, Jan Kiszka wrote: >>> On 2012-01-15 13:35, Avi Kivity wrote: On 01/15/2012 12:52 PM, Jan Kiszka wrote: > On 2012-01-15 11:49, Jan Kiszka wrote: >> On 2011-12-19 15:13, Avi Kivity wrote: >>> Drop the use of cpu_register_phys_memory_client() in favour of the new >>> MemoryListener API. The new API simplifies the caller, since there is >>> no >>> need to deal with splitting and merging slots; however this is not >>> exploited >>> in this patch. >> >> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet. > > In fact, it breaks all vga types in that scenario. > An F14 guest works here. More info, please. >>> >>> Just try to boot an openSUSE live image (or installation). Grub output >>> is corrupted, obviously dirty logging is not properly set up in that >>> graphic mode. >>> >> >> Downloading now. >> > > Wait, isn't opensuse grub2 based? Which version should I test? > My test case is 11.4-based, but I think to remember 12.1 is also still grub1 (luckily...). Jan signature.asc Description: OpenPGP digital signature
Re: qemu-kvm: Inconsistent vgabios reference
On 2012-01-15 13:49, Avi Kivity wrote: > On 01/15/2012 02:44 PM, Jan Kiszka wrote: >> OK, thanks. >> >> As that repos is now the vgabios reference, nothing valuable can be lost >> when we drop the kvm/ folder, right? >> > > I guess so. > > What about extboot w/ -M pc-0.foo? I guess we'll boot with a newer > seabios in any case, but we probably will have boot order issues. Maybe > we should make boot=on talk to the boot order code. extboot is history since 2a06024dc1b1e27b1be0266379af397e61b4a9ad Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 13/23] kvm: convert to MemoryListener API
On 01/15/2012 02:49 PM, Avi Kivity wrote: > On 01/15/2012 02:40 PM, Jan Kiszka wrote: > > On 2012-01-15 13:35, Avi Kivity wrote: > > > On 01/15/2012 12:52 PM, Jan Kiszka wrote: > > >> On 2012-01-15 11:49, Jan Kiszka wrote: > > >>> On 2011-12-19 15:13, Avi Kivity wrote: > > Drop the use of cpu_register_phys_memory_client() in favour of the new > > MemoryListener API. The new API simplifies the caller, since there is > > no > > need to deal with splitting and merging slots; however this is not > > exploited > > in this patch. > > >>> > > >>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet. > > >> > > >> In fact, it breaks all vga types in that scenario. > > >> > > > > > > An F14 guest works here. More info, please. > > > > Just try to boot an openSUSE live image (or installation). Grub output > > is corrupted, obviously dirty logging is not properly set up in that > > graphic mode. > > > > Downloading now. > Wait, isn't opensuse grub2 based? Which version should I test? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/23] kvm: convert to MemoryListener API
On 01/15/2012 02:40 PM, Jan Kiszka wrote: > On 2012-01-15 13:35, Avi Kivity wrote: > > On 01/15/2012 12:52 PM, Jan Kiszka wrote: > >> On 2012-01-15 11:49, Jan Kiszka wrote: > >>> On 2011-12-19 15:13, Avi Kivity wrote: > Drop the use of cpu_register_phys_memory_client() in favour of the new > MemoryListener API. The new API simplifies the caller, since there is no > need to deal with splitting and merging slots; however this is not > exploited > in this patch. > >>> > >>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet. > >> > >> In fact, it breaks all vga types in that scenario. > >> > > > > An F14 guest works here. More info, please. > > Just try to boot an openSUSE live image (or installation). Grub output > is corrupted, obviously dirty logging is not properly set up in that > graphic mode. > Downloading now. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 01/15/2012 02:44 PM, Jan Kiszka wrote: > OK, thanks. > > As that repos is now the vgabios reference, nothing valuable can be lost > when we drop the kvm/ folder, right? > I guess so. What about extboot w/ -M pc-0.foo? I guess we'll boot with a newer seabios in any case, but we probably will have boot order issues. Maybe we should make boot=on talk to the boot order code. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 2012-01-15 13:42, Avi Kivity wrote: > On 01/15/2012 02:39 PM, Jan Kiszka wrote: >> On 2012-01-15 13:33, Avi Kivity wrote: >>> On 01/15/2012 01:14 PM, Jan Kiszka wrote: Hi all, the vgabios hash qemu-kvm points to does not exist in the referenced repository. I was trying to find out the status of qemu-kvm's bios binaries and relevance of what is in the kvm/ folder. Looks like this is "a bit" messy... >>> >>> I have 19ea12c230ded95 for that hash, and pushing it tells me everything >>> is up to date. What hash do you see? >> >> qemu-kvm master points to ca056d8e77a534f4f90548bc8cee166a378c1454, >> after f6f8864b9b3ae1ea151c2b781792a5e72baaa178 I think. >> > > Ah, yes, I was behind. Somehow 'git submodule update' found the new > commit from me, and it's pushed now. Please try again after waiting for > git.kernel.org to catch up. OK, thanks. As that repos is now the vgabios reference, nothing valuable can be lost when we drop the kvm/ folder, right? Jan signature.asc Description: OpenPGP digital signature
Re: qemu-kvm: Inconsistent vgabios reference
On 01/15/2012 02:39 PM, Jan Kiszka wrote: > On 2012-01-15 13:33, Avi Kivity wrote: > > On 01/15/2012 01:14 PM, Jan Kiszka wrote: > >> Hi all, > >> > >> the vgabios hash qemu-kvm points to does not exist in the referenced > >> repository. I was trying to find out the status of qemu-kvm's bios > >> binaries and relevance of what is in the kvm/ folder. Looks like this is > >> "a bit" messy... > > > > I have 19ea12c230ded95 for that hash, and pushing it tells me everything > > is up to date. What hash do you see? > > qemu-kvm master points to ca056d8e77a534f4f90548bc8cee166a378c1454, > after f6f8864b9b3ae1ea151c2b781792a5e72baaa178 I think. > Ah, yes, I was behind. Somehow 'git submodule update' found the new commit from me, and it's pushed now. Please try again after waiting for git.kernel.org to catch up. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/23] kvm: convert to MemoryListener API
On 2012-01-15 13:35, Avi Kivity wrote: > On 01/15/2012 12:52 PM, Jan Kiszka wrote: >> On 2012-01-15 11:49, Jan Kiszka wrote: >>> On 2011-12-19 15:13, Avi Kivity wrote: Drop the use of cpu_register_phys_memory_client() in favour of the new MemoryListener API. The new API simplifies the caller, since there is no need to deal with splitting and merging slots; however this is not exploited in this patch. >>> >>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet. >> >> In fact, it breaks all vga types in that scenario. >> > > An F14 guest works here. More info, please. Just try to boot an openSUSE live image (or installation). Grub output is corrupted, obviously dirty logging is not properly set up in that graphic mode. Jan signature.asc Description: OpenPGP digital signature
Re: qemu-kvm: Inconsistent vgabios reference
On 2012-01-15 13:33, Avi Kivity wrote: > On 01/15/2012 01:14 PM, Jan Kiszka wrote: >> Hi all, >> >> the vgabios hash qemu-kvm points to does not exist in the referenced >> repository. I was trying to find out the status of qemu-kvm's bios >> binaries and relevance of what is in the kvm/ folder. Looks like this is >> "a bit" messy... > > I have 19ea12c230ded95 for that hash, and pushing it tells me everything > is up to date. What hash do you see? qemu-kvm master points to ca056d8e77a534f4f90548bc8cee166a378c1454, after f6f8864b9b3ae1ea151c2b781792a5e72baaa178 I think. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/3] acpi_piix4: Add stub functions for CPU eject callback
On 01/13/2012 01:11 PM, Vasilis Liaskovitis wrote: > Signed-off-by: Vasilis Liaskovitis > --- > hw/acpi_piix4.c | 15 +++ > 1 files changed, 15 insertions(+), 0 deletions(-) > > diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c > index d5743b6..8bf30dd 100644 > --- a/hw/acpi_piix4.c > +++ b/hw/acpi_piix4.c > @@ -37,6 +37,7 @@ > > #define GPE_BASE 0xafe0 > #define PROC_BASE 0xaf00 > +#define PROC_EJ_BASE 0xaf20 > We're adding stuff to piix4 which was never there. At a minimum this needs to be documented. Also needs to be -M pc-1.1 and later only. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/23] kvm: convert to MemoryListener API
On 01/15/2012 12:52 PM, Jan Kiszka wrote: > On 2012-01-15 11:49, Jan Kiszka wrote: > > On 2011-12-19 15:13, Avi Kivity wrote: > >> Drop the use of cpu_register_phys_memory_client() in favour of the new > >> MemoryListener API. The new API simplifies the caller, since there is no > >> need to deal with splitting and merging slots; however this is not > >> exploited > >> in this patch. > > > > This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet. > > In fact, it breaks all vga types in that scenario. > An F14 guest works here. More info, please. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm: Inconsistent vgabios reference
On 01/15/2012 01:14 PM, Jan Kiszka wrote: > Hi all, > > the vgabios hash qemu-kvm points to does not exist in the referenced > repository. I was trying to find out the status of qemu-kvm's bios > binaries and relevance of what is in the kvm/ folder. Looks like this is > "a bit" messy... I have 19ea12c230ded95 for that hash, and pushing it tells me everything is up to date. What hash do you see? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: do not #GP on perf MSR writes when vPMU is disabled
Return to behaviour perf MSR had before introducing vPMU in case vPMU
is disabled. Some guests access those registers unconditionally and do
not expect it to fail.
Signed-off-by: Gleb Natapov
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c95ca2d..9c912f0b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1495,6 +1495,8 @@ static void record_steal_time(struct kvm_vcpu *vcpu)
int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
{
+ bool pr = false;
+
switch (msr) {
case MSR_EFER:
return set_efer(vcpu, data);
@@ -1635,6 +1637,18 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr,
u64 data)
pr_unimpl(vcpu, "unimplemented perfctr wrmsr: "
"0x%x data 0x%llx\n", msr, data);
break;
+ case MSR_P6_PERFCTR0:
+ case MSR_P6_PERFCTR1:
+ pr = true;
+ case MSR_P6_EVNTSEL0:
+ case MSR_P6_EVNTSEL1:
+ if (kvm_pmu_msr(vcpu, msr))
+ return kvm_pmu_set_msr(vcpu, msr, data);
+
+ if (pr || data != 0)
+ pr_unimpl(vcpu, "disabled perfctr wrmsr: "
+ "0x%x data 0x%llx\n", msr, data);
+ break;
case MSR_K7_CLK_CTL:
/*
* Ignore all writes to this no longer documented MSR.
@@ -1845,6 +1859,14 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr,
u64 *pdata)
case MSR_FAM10H_MMIO_CONF_BASE:
data = 0;
break;
+ case MSR_P6_PERFCTR0:
+ case MSR_P6_PERFCTR1:
+ case MSR_P6_EVNTSEL0:
+ case MSR_P6_EVNTSEL1:
+ if (kvm_pmu_msr(vcpu, msr))
+ return kvm_pmu_get_msr(vcpu, msr, pdata);
+ data = 0;
+ break;
case MSR_IA32_UCODE_REV:
data = 0x1ULL;
break;
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/1] QEMU kvm/i386 : Adding PVLOCK_KICK capability support in i386 target.
From: Raghavendra K T
The patch, extends KVM-hypervisor and Linux guest running on
KVM-hypervisor to support pv-ticket spinlocks.
PV ticket spinlock helps to solve Lock Holder Preemption problem discussed in
http://www.amd64.org/fileadmin/user_upload/pub/LHP-commented_slides.pdf.
When spinlock is contended,a guest vcpu relinqueshes cpu by halt().
Correspondingly, One hypercall is introduced in KVM hypervisor,that allows
a vcpu to kick the halted vcpu to continue with execution.
Note:
Below patch should be applied only after corresponding
linux-header changes taken into qemu via scripts/update-linux-headers.sh script.
TODO: There was a discussion on changing cpuid stuff, paravirt and non-paravirt
stuff to address backward compatibility/feature support with Avi and Jan.
But it is not addressed yet.
Changes in V2:
Drop the syncing kernel header changes. (Alex)
rename KICK_VCPU --> PVLOCK_KICK.
Change log:
Extend the KVM Hypervisor to enable PVLOCK_KICK feature that allows
a vcpu to kick the halted vcpu to continue with execution in PV ticket
spinlock.
Signed-off-by: Srivatsa Vaddagiri
Signed-off-by: Raghavendra K T
---
The corresponding kernel patch is available in the thread
https://lkml.org/lkml/2012/1/14/66
older kernel patch:
https://lkml.org/lkml/2011/11/30/62
older qemu-patch:
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 04e65c5..14de1c0 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -97,6 +97,7 @@ struct kvm_para_features {
{ KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
{ KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
{ KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+{ KVM_CAP_PVLOCK_KICK, KVM_FEATURE_PVLOCK_KICK },
{ -1, -1 }
};
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
qemu-kvm: Inconsistent vgabios reference
Hi all, the vgabios hash qemu-kvm points to does not exist in the referenced repository. I was trying to find out the status of qemu-kvm's bios binaries and relevance of what is in the kvm/ folder. Looks like this is "a bit" messy... Jan signature.asc Description: OpenPGP digital signature
[PATCH] qemu-kvm: Deprecate time drift fix
From: Jan Kiszka
Remove this divergence from upstream. It is practically unused today as
the default mode is in-kernel irqchip. We keep the command line switch
for now, adding a warning that there is no effect anymore.
The feature can be reintroduced to upstream once we have IRQ paths with
feedback support.
Signed-off-by: Jan Kiszka
---
hw/i8254.c | 28 ++--
hw/i8259.c | 17 -
qemu-options.hx |4 ++--
vl.c|4 ++--
4 files changed, 6 insertions(+), 47 deletions(-)
diff --git a/hw/i8254.c b/hw/i8254.c
index d73a5f2..50ecceb 100644
--- a/hw/i8254.c
+++ b/hw/i8254.c
@@ -347,11 +347,6 @@ static uint32_t pit_ioport_read(void *opaque, uint32_t
addr)
return ret;
}
-/* global counters for time-drift fix */
-int64_t timer_acks=0, timer_interrupts=0, timer_ints_to_push=0;
-
-extern int time_drift_fix;
-
static void pit_irq_timer_update(PITChannelState *s, int64_t current_time)
{
int64_t expire_time;
@@ -362,35 +357,16 @@ static void pit_irq_timer_update(PITChannelState *s,
int64_t current_time)
expire_time = pit_get_next_transition_time(s, current_time);
irq_level = pit_get_out1(s, current_time);
qemu_set_irq(s->irq, irq_level);
-if (time_drift_fix && irq_level==1) {
-/* FIXME: fine tune timer_max_fix (max fix per tick).
- *Should it be 1 (double time), 2 , 4, 10 ?
- *Currently setting it to 5% of PIT-ticks-per-second (per
PIT-tick)
- */
-const long pit_ticks_per_sec = (s->count>0) ? (PIT_FREQ/s->count) : 0;
-const long timer_max_fix = pit_ticks_per_sec/20;
-const long delta = timer_interrupts - timer_acks;
-const long max_delta = pit_ticks_per_sec * 60; /* one minute */
-if ((delta > max_delta) && (pit_ticks_per_sec > 0)) {
-printf("time drift is too long, %ld seconds were lost\n",
delta/pit_ticks_per_sec);
-timer_acks = timer_interrupts;
-timer_ints_to_push = 0;
-} else if (delta > 0) {
-timer_ints_to_push = MIN(delta, timer_max_fix);
-}
-timer_interrupts++;
-}
#ifdef DEBUG_PIT
printf("irq_level=%d next_delay=%f\n",
irq_level,
(double)(expire_time - current_time) / get_ticks_per_sec());
#endif
s->next_transition_time = expire_time;
-if (expire_time != -1) {
+if (expire_time != -1)
qemu_mod_timer(s->irq_timer, expire_time);
-} else {
+else
qemu_del_timer(s->irq_timer);
-}
}
static void pit_irq_timer(void *opaque)
diff --git a/hw/i8259.c b/hw/i8259.c
index 7e17071..0632ea2 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -210,9 +210,6 @@ static void pic_intack(PicState *s, int irq)
pic_update_irq(s);
}
-extern int time_drift_fix;
-extern int64_t timer_acks, timer_ints_to_push;
-
int pic_read_irq(PicState *s)
{
int irq, irq2, intno;
@@ -232,20 +229,6 @@ int pic_read_irq(PicState *s)
intno = s->irq_base + irq;
}
pic_intack(s, irq);
-
-/* FIXME: limit to x86, or better, to platforms where irq0 is the
- * timer interrupts. */
-
- if (time_drift_fix && s->master && irq == 0) {
- timer_acks++;
- if (timer_ints_to_push > 0) {
- timer_ints_to_push--;
-/* simulate an edge irq0, like the one generated by i8254 */
-pic_set_irq(s, 0, 0);
-pic_set_irq(s, 0, 1);
- }
- }
-
} else {
/* spurious IRQ on host controller */
irq = 7;
diff --git a/qemu-options.hx b/qemu-options.hx
index c645f87..d567ba3 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2633,8 +2633,8 @@ DEF("no-kvm-pit-reinjection", 0,
QEMU_OPTION_no_kvm_pit_reinjection,
"-no-kvm-pit-reinjection\n"
"disable KVM kernel mode PIT interrupt reinjection\n",
QEMU_ARCH_I386)
-DEF("tdf", 0, QEMU_OPTION_tdf,
-"-tdfenable guest time drift compensation\n", QEMU_ARCH_ALL)
+HXCOMM -tdf is deprecated and ignored today
+DEF("tdf", 0, QEMU_OPTION_tdf, "", QEMU_ARCH_ALL)
DEF("kvm-shadow-memory", HAS_ARG, QEMU_OPTION_kvm_shadow_memory,
"-kvm-shadow-memory MEGABYTES\n"
"allocate MEGABYTES for kvm mmu shadowing\n",
diff --git a/vl.c b/vl.c
index c009eb8..1a77de1 100644
--- a/vl.c
+++ b/vl.c
@@ -222,7 +222,6 @@ const char *watchdog;
QEMUOptionRom option_rom[MAX_OPTION_ROMS];
int nb_option_roms;
int semihosting_enabled = 0;
-int time_drift_fix = 0;
unsigned int kvm_shadow_memory = 0;
int old_param = 0;
const char *qemu_name;
@@ -2955,7 +2954,8 @@ int main(int argc, char **argv, char **envp)
semihosting_enabled = 1;
break;
case QEMU_OPTION_tdf:
-time_drift_fix = 1;
+fprintf(stderr, "Warning: user space PIT time drift fix "
+"is no longer supported.\n");
Re: [PATCH 13/23] kvm: convert to MemoryListener API
On 2012-01-15 11:49, Jan Kiszka wrote: > On 2011-12-19 15:13, Avi Kivity wrote: >> Drop the use of cpu_register_phys_memory_client() in favour of the new >> MemoryListener API. The new API simplifies the caller, since there is no >> need to deal with splitting and merging slots; however this is not exploited >> in this patch. > > This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet. In fact, it breaks all vga types in that scenario. Jan signature.asc Description: OpenPGP digital signature
Re: [PATCH 13/23] kvm: convert to MemoryListener API
On 2011-12-19 15:13, Avi Kivity wrote:
> Drop the use of cpu_register_phys_memory_client() in favour of the new
> MemoryListener API. The new API simplifies the caller, since there is no
> need to deal with splitting and merging slots; however this is not exploited
> in this patch.
This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.
Jan
>
> Signed-off-by: Avi Kivity
> ---
> kvm-all.c | 107
> -
> 1 files changed, 70 insertions(+), 37 deletions(-)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 4f58ae8..138e0a2 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -27,6 +27,7 @@
> #include "gdbstub.h"
> #include "kvm.h"
> #include "bswap.h"
> +#include "memory.h"
>
> /* This check must be after config-host.h is included */
> #ifdef CONFIG_EVENTFD
> @@ -289,16 +290,28 @@ static int
> kvm_dirty_pages_log_change(target_phys_addr_t phys_addr,
> return kvm_slot_dirty_pages_log_change(mem, log_dirty);
> }
>
> -static int kvm_log_start(CPUPhysMemoryClient *client,
> - target_phys_addr_t phys_addr, ram_addr_t size)
> +static void kvm_log_start(MemoryListener *listener,
> + MemoryRegionSection *section)
> {
> -return kvm_dirty_pages_log_change(phys_addr, size, true);
> +int r;
> +
> +r = kvm_dirty_pages_log_change(section->offset_within_address_space,
> + section->size, true);
> +if (r < 0) {
> +abort();
> +}
> }
>
> -static int kvm_log_stop(CPUPhysMemoryClient *client,
> -target_phys_addr_t phys_addr, ram_addr_t size)
> +static void kvm_log_stop(MemoryListener *listener,
> + MemoryRegionSection *section)
> {
> -return kvm_dirty_pages_log_change(phys_addr, size, false);
> +int r;
> +
> +r = kvm_dirty_pages_log_change(section->offset_within_address_space,
> + section->size, false);
> +if (r < 0) {
> +abort();
> +}
> }
>
> static int kvm_set_migration_log(int enable)
> @@ -519,13 +532,15 @@ static int kvm_check_many_ioeventfds(void)
> return NULL;
> }
>
> -static void kvm_set_phys_mem(target_phys_addr_t start_addr, ram_addr_t size,
> - ram_addr_t phys_offset, bool log_dirty)
> +static void kvm_set_phys_mem(MemoryRegionSection *section, bool add)
> {
> KVMState *s = kvm_state;
> -ram_addr_t flags = phys_offset & ~TARGET_PAGE_MASK;
> KVMSlot *mem, old;
> int err;
> +MemoryRegion *mr = section->mr;
> +bool log_dirty = memory_region_is_logging(mr);
> +target_phys_addr_t start_addr = section->offset_within_address_space;
> +ram_addr_t size = section->size;
> void *ram = NULL;
>
> /* kvm works in page size chunks, but the function may be called
> @@ -533,20 +548,19 @@ static void kvm_set_phys_mem(target_phys_addr_t
> start_addr, ram_addr_t size,
> size = TARGET_PAGE_ALIGN(size);
> start_addr = TARGET_PAGE_ALIGN(start_addr);
>
> -/* KVM does not support read-only slots */
> -phys_offset &= ~IO_MEM_ROM;
> -
> -if ((phys_offset & ~TARGET_PAGE_MASK) == IO_MEM_RAM) {
> -ram = qemu_safe_ram_ptr(phys_offset);
> +if (!memory_region_is_ram(mr)) {
> +return;
> }
>
> +ram = memory_region_get_ram_ptr(mr) + section->offset_within_region;
> +
> while (1) {
> mem = kvm_lookup_overlapping_slot(s, start_addr, start_addr + size);
> if (!mem) {
> break;
> }
>
> -if (flags < IO_MEM_UNASSIGNED && start_addr >= mem->start_addr &&
> +if (add && start_addr >= mem->start_addr &&
> (start_addr + size <= mem->start_addr + mem->memory_size) &&
> (ram - start_addr == mem->ram - mem->start_addr)) {
> /* The new slot fits into the existing one and comes with
> @@ -575,8 +589,7 @@ static void kvm_set_phys_mem(target_phys_addr_t
> start_addr, ram_addr_t size,
> * slot comes around later, we will fail (not seen in practice so
> far)
> * - and actually require a recent KVM version. */
> if (s->broken_set_mem_region &&
> -old.start_addr == start_addr && old.memory_size < size &&
> -flags < IO_MEM_UNASSIGNED) {
> +old.start_addr == start_addr && old.memory_size < size && add) {
> mem = kvm_alloc_slot(s);
> mem->memory_size = old.memory_size;
> mem->start_addr = old.start_addr;
> @@ -591,7 +604,6 @@ static void kvm_set_phys_mem(target_phys_addr_t
> start_addr, ram_addr_t size,
> }
>
> start_addr += old.memory_size;
> -phys_offset += old.memory_size;
> ram += old.memory_size;
> size -= old.memory_size;
> continue;
> @@ -642,8 +654,7 @@ static void kvm_set_phys_mem(target_phys_addr_t
> start_addr, ram_addr_t size,
>
Re: [PATCH] KVM: Fix MOVSX emulation
On 01/14/2012 08:34 PM, Nadav Amit wrote: > The destination register of MOVSX should be decoded similarily to MOVZX. > > Signed-off-by: Nadav Amit > --- > arch/x86/kvm/emulate.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > index 05a562b..7644a83 100644 > --- a/arch/x86/kvm/emulate.c > +++ b/arch/x86/kvm/emulate.c > @@ -3553,7 +3553,8 @@ static int decode_operand(struct x86_emulate_ctxt > *ctxt, struct operand *op, > case OpReg: > decode_register_operand(ctxt, op, >op == &ctxt->dst && > - ctxt->twobyte && (ctxt->b == 0xb6 || ctxt->b == 0xb7)); > + ctxt->twobyte && ((ctxt->b & 0xfe) == 0xb6 || > + (ctxt->b & 0xfe) == 0xbe)); > break; > case OpImmUByte: > rc = decode_imm(ctxt, op, 1, false); Please post a unit test for this. See git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git x86/emulate.c. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
