Re: KVM: cdrom passthrough?

[Amit Shah]

On (Wed) Jul 08 2009 [16:19:27], Dâniel Fraga wrote:
   I like very much KVM, but I decided to test Virtualbox and it
 has nice features KVM doesn't have. BUT... Virtualbox is orders of
 magnitude SLOWER than KVM. Virtualbox just can't compete with KVM
 regarding speed. KVM is much, much, much faster than any virtual
 machine on earth.
 
   Anyway, Virtualbox has a nice feature: cdrom passthrough with
 let me use applications like AnyDVD or something like that. That's the
 only app I need which there is not an equivalent in Linux.
 
   So, I know that I can use -cdrom /mountpoint, but AnyDVD won't
 work with that. Besides that, Virtualbox allows me to mount/umount
 whenever I want without restarting the virtual machine.

You can use the monitor command 'change' to do that. Though you should
be using a frontend like virt-manager which should have such
functionality.

   So, is there any way to force cdrom passthrough in KVM or it is
 impossible right now?

I think this feature is under development and is discussed on the qemu
list.

Amit
--
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: KVM and kernel 2.6.30 file system madness

[Amit Shah]

On (Thu) Jul 09 2009 [08:27:48], Robert Wimmer wrote:
 Hi there,
 
 back in days before kernel 2.6.25/2.6.26 and KVM 70-77 KVM decided to
 crash from time to time. That time we used XFS as filesystem (/ and /boot
 where ext3/ext2). Since XFS worked so very well for us on physical
 hosts the natural choise for our OSs in KVM of course was also XFS.
 This was a bad idea because it caused some filesystem corruptions
 on some KVMs when KVM crashed (without any message).
 Somewhere I read that XFS in KVM should only be used with the
 KVM parameter cache=none. Since then this is now our default
 for all KVMs (even with ext3). I thought by myself that KVM and an FS which
 does heavy write caching like XFS is a bad choise so I decided that I can't
 trust XFS inside a KVM anymore and so I switched all filesystems
 in our KVMs to ext3. This was a good choice. No FS corruptions
 anymore - well and no unplaned crashes of of KVM too ;-)
 Since yesterday (no crash but FS corruptions)...
 
 I installed kernel 2.6.30-r2 in one of our guests. This was a not so
 good idea. All hosts and guest running Gentoo. Host kernel is 2.6.29-r5
 and KVM is 84 (KVM 85 has issues with VNC display and 86 and
 87 not in portage currently). Using qow2 as KVM image format.
 
 I installed all the stuff we needed in the new KVM and a Postgres
 database. But something was different. The database import was
 suddenly fast as hell. I've never seen such good I/O throughput
 in a KVM. Well after almost finished with the whole installation
 process I noticed some strange ext3 messages in the dmesg
 output. Oh no... Not again problems with FS corruptions I thought...
 Well after a reboot of the KVM it was sure that the rootfs was
 corrupted. /etc/hostname and some other files suddenly were
 binary files :-( Lukely I was able to correct the problems with
 fsck and get the files back from the backup.
 
 So what happend in 2.6.30? Ah... I remembered immediately that
 the kernel developers decided to switch the default value of the
 journaling mode (data=...) from ordered to writeback. Well...
 Now I know why the database import was so fast... But at what
 price? I'm really curious what happens when the major distributions
 roll out their distributions with this default option.

Distributions will likely change the default.

 So my question is: I'm the only one in the universe with this
 FS problems? Am I completely wrong here? Is data=ordered
 the recommended mode for ext3 in KVMs and even necessary
 when KVM ist not crashing?  This kind of stuff sometimes makes
 live to so easy... ;-)

Are you using virtio-block?

In any case, not using a released version always has risks.

Amit
--
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 process is running at 100% CPU, but no response from guest

[Amit Shah]

On (Thu) Jul 09 2009 [07:18:54], Ján ONDREJ (SAL) wrote:
 Hello,
 
   today I have second incident, that my qemu-kvm process is running at 100%
 or 200% CPU (watched using top program), but there is no response from guest
 long time (some hours). First time lots of these messages appeared in dmesg:
 
 vcpu not ready for apic_round_robin
 vcpu not ready for apic_round_robin
 vcpu not ready for apic_round_robin
 
 Second time nothing, only process was run at 200% CPU:
 
 top - 06:23:14 up 4 days, 11:06,  1 user,  load average: 2.26, 2.15, 2.18
 Tasks: 126 total,   1 running, 125 sleeping,   0 stopped,   0 zombie
 Cpu(s): 50.2%us,  0.4%sy,  0.0%ni, 49.1%id,  0.2%wa,  0.0%hi,  0.1%si,
 0.0%st
 Mem:   8047368k total,  8004516k used,42852k free,  1507160k buffers
 Swap:  8388600k total,57284k used,  8331316k free,79700k cached
 
   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND  
  
 17110 root  20   0 4417m 3.9g 1464 S 201.3 50.9   1326:34 qemu-kvm
  9886 root  20   0 2519m 1.9g 1376 S  1.7 25.1  72:40.73 qemu-kvm

What's the command line you used to start the guests?

 Serial console without response too in boch cases, no ping to guest.
 
 My current configuration is an fully updated Fedora 11 host and updated
 Fedora 10 guest. KVM is from package qemu-kvm-0.10.5-3.fc11.x86_64.
 
Amit
--
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 -v6] QEMU-KVM: MCE: Add MCE simulation support to qemu/kvm

[Huang Ying]

KVM ioctls are used to initialize MCE simulation and inject MCE. The
real MCE simulation is implemented in Linux kernel. The Kernel part
has been merged.


ChangeLog:

v6:

- Re-based on latest qemu-kvm.git

v5:

- Re-based on latest qemu-kvm.git

v3:

- Re-based on qemu/tcg MCE support patch

v2:

- Use new kernel MCE capability exportion interface.


Signed-off-by: Huang Ying ying.hu...@intel.com

---
 kvm/include/linux/kvm.h   |   20 
 kvm/include/x86/asm/kvm.h |1 
 libkvm-all.h  |4 +++
 qemu-kvm-x86.c|   55 ++
 qemu-kvm.c|   40 +
 qemu-kvm.h|3 ++
 target-i386/helper.c  |5 
 target-i386/machine.c |4 +--
 8 files changed, 130 insertions(+), 2 deletions(-)

--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -444,6 +444,39 @@ int kvm_set_msrs(kvm_vcpu_context_t vcpu
 return r;
 }
 
+int kvm_get_mce_cap_supported(kvm_context_t kvm, uint64_t *mce_cap,
+  int *max_banks)
+{
+#ifdef KVM_CAP_MCE
+int r;
+
+r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_MCE);
+if (r  0) {
+*max_banks = r;
+return ioctl(kvm-fd, KVM_X86_GET_MCE_CAP_SUPPORTED, mce_cap);
+}
+#endif
+return -ENOSYS;
+}
+
+int kvm_setup_mce(kvm_vcpu_context_t vcpu, uint64_t *mcg_cap)
+{
+#ifdef KVM_CAP_MCE
+return ioctl(vcpu-fd, KVM_X86_SETUP_MCE, mcg_cap);
+#else
+return -ENOSYS;
+#endif
+}
+
+int kvm_set_mce(kvm_vcpu_context_t vcpu, struct kvm_x86_mce *m)
+{
+#ifdef KVM_CAP_MCE
+return ioctl(vcpu-fd, KVM_X86_SET_MCE, m);
+#else
+return -ENOSYS;
+#endif
+}
+
 static void print_seg(FILE *file, const char *name, struct kvm_segment *seg)
 {
fprintf(stderr,
@@ -1301,6 +1334,28 @@ int kvm_arch_qemu_init_env(CPUState *cen
 
 kvm_setup_cpuid2(cenv-kvm_cpu_state.vcpu_ctx, cpuid_nent, cpuid_ent);
 
+#ifdef KVM_CAP_MCE
+if (((cenv-cpuid_version  8)0xF) = 6
+ (cenv-cpuid_features(CPUID_MCE|CPUID_MCA)) == 
(CPUID_MCE|CPUID_MCA)
+ kvm_check_extension(kvm_context, KVM_CAP_MCE)  0) {
+uint64_t mcg_cap;
+int banks;
+
+if (kvm_get_mce_cap_supported(kvm_context, mcg_cap, banks))
+perror(kvm_get_mce_cap_supported FAILED);
+else {
+if (banks  MCE_BANKS_DEF)
+banks = MCE_BANKS_DEF;
+mcg_cap = MCE_CAP_DEF;
+mcg_cap |= banks;
+if (kvm_setup_mce(cenv-kvm_cpu_state.vcpu_ctx, mcg_cap))
+perror(kvm_setup_mce FAILED);
+else
+cenv-mcg_cap = mcg_cap;
+}
+}
+#endif
+
 return 0;
 }
 
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -241,4 +241,7 @@ static inline int kvm_set_migration_log(
 return kvm_physical_memory_set_dirty_tracking(enable);
 }
 
+void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
+uint64_t mcg_status, uint64_t addr, uint64_t misc);
+
 #endif
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1509,6 +1509,11 @@ void cpu_inject_x86_mce(CPUState *cenv, 
 unsigned bank_num = mcg_cap  0xff;
 uint64_t *banks = cenv-mce_banks;
 
+if (kvm_enabled()) {
+kvm_inject_x86_mce(cenv, bank, status, mcg_status, addr, misc);
+return;
+}
+
 if (bank = bank_num || !(status  MCI_STATUS_VAL))
 return;
 
--- a/kvm/include/linux/kvm.h
+++ b/kvm/include/linux/kvm.h
@@ -463,6 +463,9 @@ struct kvm_trace_rec {
 #define KVM_CAP_ASSIGN_DEV_IRQ 29
 /* Another bug in KVM_SET_USER_MEMORY_REGION fixed: */
 #define KVM_CAP_JOIN_MEMORY_REGIONS_WORKS 30
+#ifdef __KVM_HAVE_MCE
+#define KVM_CAP_MCE 31
+#endif
 #define KVM_CAP_PIT2 33
 #define KVM_CAP_PIT_STATE2 35
 
@@ -504,6 +507,19 @@ struct kvm_irq_routing {
 
 #endif
 
+#ifdef KVM_CAP_MCE
+/* x86 MCE */
+struct kvm_x86_mce {
+   __u64 status;
+   __u64 addr;
+   __u64 misc;
+   __u64 mcg_status;
+   __u8 bank;
+   __u8 pad1[7];
+   __u64 pad2[3];
+};
+#endif
+
 /*
  * ioctls for VM fds
  */
@@ -592,6 +608,10 @@ struct kvm_irq_routing {
 #define KVM_NMI   _IO(KVMIO,  0x9a)
 /* Available with KVM_CAP_SET_GUEST_DEBUG */
 #define KVM_SET_GUEST_DEBUG   _IOW(KVMIO,  0x9b, struct kvm_guest_debug)
+/* MCE for x86 */
+#define KVM_X86_SETUP_MCE _IOW(KVMIO,  0x9c, __u64)
+#define KVM_X86_GET_MCE_CAP_SUPPORTED _IOR(KVMIO,  0x9d, __u64)
+#define KVM_X86_SET_MCE   _IOW(KVMIO,  0x9e, struct kvm_x86_mce)
 
 /*
  * Deprecated interfaces
--- a/kvm/include/x86/asm/kvm.h
+++ b/kvm/include/x86/asm/kvm.h
@@ -57,6 +57,7 @@
 #define __KVM_HAVE_USER_NMI
 #define __KVM_HAVE_GUEST_DEBUG
 #define __KVM_HAVE_MSIX
+#define __KVM_HAVE_MCE
 
 /* Architectural interrupt line count. */
 #define KVM_NR_INTERRUPTS 256
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2845,3 +2845,43 @@ int kvm_set_boot_cpu_id(uint32_t id)
 {
return kvm_set_boot_vcpu_id(kvm_context, id);
 }
+
+#ifdef 

[PATCH] rev5: support colon in filenames

[Ram Pai]

Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name scsi.

This patch allows user to espace colon characters. For example the above
filename can now be expressed either as 'scsi\:0' or as file:scsi:0

anything following the file: tag is interpreted verbatin. However if file:
tag is omitted then any colon characters in the string must be escaped using
backslash.

Here are couple of examples:

scsi\:0\:abc is a local file scsi:0:abc
http\://myweb is a local file by name http://myweb
file:scsi:0:abc is a local file scsi:0:abc
file:http://myweb is a local file by name http://myweb

fat:c:\path\to\dir\:floppy\:  is a fat file by name \path\to\dir:floppy:
NOTE:The above example cannot be expressed using the file: protocol.


Changelog w.r.t to iteration 0:
   1) removes flexibility added to nbd semantics  eg -- nbd:\::
   2) introduce the file: protocol to indicate local file

Changelog w.r.t to iteration 1:
   1) generically handles 'file:' protocol in find_protocol
   2) centralizes 'filename' pruning before the call to open().
   3) fixes buffer overflow seen in fill_token()
   4) adheres to codying style
   5) patch against upstream qemu tree

Changelog w.r.t to iteration 2:
   1) really really fixes buffer overflow seen in 
fill_token() (if not, beat me :)
   2) the centralized 'filename' pruning had a side effect with
qcow2 files and other files. Fixed it. _open() is back.

Changelog w.r.t to iteration 3:
   1) support added to raw-win32.c (i do not have the setup to 
test this change. Request help with testing)
   2) ability to espace option-values containing commas using 
backslashes 
eg  file=file:abc,,  can also be expressed as file=file:abc\, 
where 'abc,' is a filename
   3) fixes a bug (reported by Jan Kiszka) w.r.t support for -snapshot
   4) renamed _open() to qemu_open() and removed dependency on PATH_MAX

Changelog w.r.t to iteration 4:
   1) applies to upstream qemu and qemu-kvm tree
   

Signed-off-by: Ram Pai linux...@us.ibm.com


 block.c   |   30 +++-
 block/raw-posix.c |   35 ++
 block/raw-win32.c |   26 --
 block/vvfat.c |   97 -
 cutils.c  |   26 +
 qemu-common.h |1 +
 qemu-option.c |8 -
 8 files changed, 185 insertions(+), 38 deletions(-)

diff --git a/block.c b/block.c
index cefbe77..178edcc 100644
--- a/block.c
+++ b/block.c
@@ -225,7 +225,6 @@ static BlockDriver *find_protocol(const char *filename)
 {
 BlockDriver *drv1;
 char protocol[128];
-int len;
 const char *p;
 
 #ifdef _WIN32
@@ -233,14 +232,9 @@ static BlockDriver *find_protocol(const char *filename)
 is_windows_drive_prefix(filename))
 return bdrv_find_format(raw);
 #endif
-p = strchr(filename, ':');
-if (!p)
+p = prune_strcpy(protocol, sizeof(protocol), filename, ':');
+if (*p != ':')
 return bdrv_find_format(raw);
-len = p - filename;
-if (len  sizeof(protocol) - 1)
-len = sizeof(protocol) - 1;
-memcpy(protocol, filename, len);
-protocol[len] = '\0';
 for(drv1 = first_drv; drv1 != NULL; drv1 = drv1-next) {
 if (drv1-protocol_name 
 !strcmp(drv1-protocol_name, protocol))
@@ -330,8 +324,6 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, 
int flags,
BlockDriver *drv)
 {
 int ret, open_flags;
-char tmp_filename[PATH_MAX];
-char backing_filename[PATH_MAX];
 
 bs-read_only = 0;
 bs-is_temporary = 0;
@@ -343,9 +335,9 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, 
int flags,
 if (flags  BDRV_O_SNAPSHOT) {
 BlockDriverState *bs1;
 int64_t total_size;
-int is_protocol = 0;
 BlockDriver *bdrv_qcow2;
 QEMUOptionParameter *options;
+char tmp_filename[PATH_MAX];
 
 /* if snapshot, we create a temporary backing file and open it
instead of opening 'filename' directly */
@@ -359,25 +351,15 @@ int bdrv_open2(BlockDriverState *bs, const char 
*filename, int flags,
 }
 total_size = bdrv_getlength(bs1)  SECTOR_BITS;
 
-if (bs1-drv  bs1-drv-protocol_name)
-is_protocol = 1;
-
 bdrv_delete(bs1);
 
 get_tmp_filename(tmp_filename, sizeof(tmp_filename));
 
-/* Real path is meaningless for protocols */
-if (is_protocol)
-snprintf(backing_filename, sizeof(backing_filename),
- %s, filename);
-else
-realpath(filename, backing_filename);
-
 bdrv_qcow2 = bdrv_find_format(qcow2);
 options = parse_option_parameters(, bdrv_qcow2-create_options, 
NULL);
 
 set_option_parameter_int(options, BLOCK_OPT_SIZE, total_size * 

Re: KVM and kernel 2.6.30 file system madness

[Robert Wimmer]

Hi!

 Are you using virtio-block?

Yes.

 In any case, not using a released version always has risks.

Well, what do you mean by not using a released version?
The package gentoo-sources always uses released
kernels. 2.6.30-r2 in Gentoo means that this is the third
update of the stable kernel version 2.6.30. The -r* releases
just contains small patches from the Gentoo kernel package
maintainers.

Thanks!
Robert


Amit Shah wrote:
 On (Thu) Jul 09 2009 [08:27:48], Robert Wimmer wrote:
   
 Hi there,

 back in days before kernel 2.6.25/2.6.26 and KVM 70-77 KVM decided to
 crash from time to time. That time we used XFS as filesystem (/ and /boot
 where ext3/ext2). Since XFS worked so very well for us on physical
 hosts the natural choise for our OSs in KVM of course was also XFS.
 This was a bad idea because it caused some filesystem corruptions
 on some KVMs when KVM crashed (without any message).
 Somewhere I read that XFS in KVM should only be used with the
 KVM parameter cache=none. Since then this is now our default
 for all KVMs (even with ext3). I thought by myself that KVM and an FS which
 does heavy write caching like XFS is a bad choise so I decided that I can't
 trust XFS inside a KVM anymore and so I switched all filesystems
 in our KVMs to ext3. This was a good choice. No FS corruptions
 anymore - well and no unplaned crashes of of KVM too ;-)
 Since yesterday (no crash but FS corruptions)...

 I installed kernel 2.6.30-r2 in one of our guests. This was a not so
 good idea. All hosts and guest running Gentoo. Host kernel is 2.6.29-r5
 and KVM is 84 (KVM 85 has issues with VNC display and 86 and
 87 not in portage currently). Using qow2 as KVM image format.

 I installed all the stuff we needed in the new KVM and a Postgres
 database. But something was different. The database import was
 suddenly fast as hell. I've never seen such good I/O throughput
 in a KVM. Well after almost finished with the whole installation
 process I noticed some strange ext3 messages in the dmesg
 output. Oh no... Not again problems with FS corruptions I thought...
 Well after a reboot of the KVM it was sure that the rootfs was
 corrupted. /etc/hostname and some other files suddenly were
 binary files :-( Lukely I was able to correct the problems with
 fsck and get the files back from the backup.

 So what happend in 2.6.30? Ah... I remembered immediately that
 the kernel developers decided to switch the default value of the
 journaling mode (data=...) from ordered to writeback. Well...
 Now I know why the database import was so fast... But at what
 price? I'm really curious what happens when the major distributions
 roll out their distributions with this default option.
 

 Distributions will likely change the default.

   
 So my question is: I'm the only one in the universe with this
 FS problems? Am I completely wrong here? Is data=ordered
 the recommended mode for ext3 in KVMs and even necessary
 when KVM ist not crashing?  This kind of stuff sometimes makes
 live to so easy... ;-)
 

 Are you using virtio-block?

 In any case, not using a released version always has risks.

   Amit
   

--
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 process is running at 100% CPU, but no response from guest

[SAL]

On Wed, Jul 15, 2009 at 12:51:33PM +0530, Amit Shah wrote:
 On (Thu) Jul 09 2009 [07:18:54], Ján ONDREJ (SAL) wrote:
PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 
  17110 root  20   0 4417m 3.9g 1464 S 201.3 50.9   1326:34 qemu-kvm
   9886 root  20   0 2519m 1.9g 1376 S  1.7 25.1  72:40.73 qemu-kvm
 
 What's the command line you used to start the guests?

Guest was started using libvirt.

Looks that problem is somewhere in bounce code, more info in another thread:
  http://marc.info/?l=kvmm=124756938002626w=2
My CPU usage is growing after kernel panic. With panic=60 my guest is
restarted and runs some time again.

I am now experiencing with IDE dirves instead of virtio, so I can't send you
qemu-kvm original command line. With IDE drives there was no problem
tonight.

Thank you.

SAL
--
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 0.10.50 CAN NOT get ip from dhcp server

[John Wong]

Yes, kvm-88 fixed this problem.

I also notice another problem, when i use kvm-88(qemu-system-x86_64 with 
kvm-kmod-2.6.30.1-rc2.tar.gz) installing 64bit OS (window7  debian  
netbsd),
the install CD show the error message, say this system is 32bit not 
64bit and can not continue to install.

I did try use -cpu qemu64 or -cpu core2duo, but no help.


When i use kvm-85 (which from debian's package) with 
kvm-kmod-2.6.30.1-rc2.tar.gz, i can install 64bit OS.


My host system is(uname -a): Linux Debian 2.6.30-1-amd64 #1 SMP Wed Jul 
8 12:20:34 UTC 2009 x86_64 GNU/Linux

My cpu is Intel core2duo E8400.

Please help, thank you.

Amit Shah 提到:

On (Mon) Jul 06 2009 [10:13:12], John Wong wrote:
  

I notice that, when i use qemu 0.10.50 (which from kvm-0.87.tar.gz), the
guest OS CAN NOT get the ip from dhcp server.
When i use qemu 0.10.0 (which from debian's kvm-0.85 package), the guest
OS CAN get the ip from the SAME dhcp server.



This was fixed in kvm-88.

Amit
  


--
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: KVM and kernel 2.6.30 file system madness

[Amit Shah]

On (Wed) Jul 15 2009 [09:52:36], Robert Wimmer wrote:
 Hi!
 
  Are you using virtio-block?
 
 Yes.

OK, then there is a known problem. I think the fix is waiting to be
applied.

  In any case, not using a released version always has risks.
 
 Well, what do you mean by not using a released version?
 The package gentoo-sources always uses released
 kernels. 2.6.30-r2 in Gentoo means that this is the third
 update of the stable kernel version 2.6.30. The -r* releases
 just contains small patches from the Gentoo kernel package
 maintainers.

Nevermind; I thought it was a -rc2 release you're working with.

Amit
--
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 process is running at 100% CPU, but no response from guest

[Amit Shah]

On (Wed) Jul 15 2009 [09:58:51], Ján ONDREJ (SAL) wrote:
 On Wed, Jul 15, 2009 at 12:51:33PM +0530, Amit Shah wrote:
  On (Thu) Jul 09 2009 [07:18:54], Ján ONDREJ (SAL) wrote:
 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND  

   17110 root  20   0 4417m 3.9g 1464 S 201.3 50.9   1326:34 qemu-kvm
9886 root  20   0 2519m 1.9g 1376 S  1.7 25.1  72:40.73 qemu-kvm
  
  What's the command line you used to start the guests?
 
 Guest was started using libvirt.
 
 Looks that problem is somewhere in bounce code, more info in another thread:
   http://marc.info/?l=kvmm=124756938002626w=2
 My CPU usage is growing after kernel panic. With panic=60 my guest is
 restarted and runs some time again.
 
 I am now experiencing with IDE dirves instead of virtio, so I can't send you
 qemu-kvm original command line. With IDE drives there was no problem
 tonight.

OK, the virtio-block code has a known bug which you might be hitting.

Amit
--
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] rev5: support colon in filenames

[Jan Kiszka]

Ram Pai wrote:
 Problem: It is impossible to feed filenames with the character colon because
 qemu interprets such names as a protocol. For example filename scsi:0, is
 interpreted as a protocol by name scsi.
 
 This patch allows user to espace colon characters. For example the above
 filename can now be expressed either as 'scsi\:0' or as file:scsi:0
 
 anything following the file: tag is interpreted verbatin. However if file:
 tag is omitted then any colon characters in the string must be escaped using
 backslash.
 
 Here are couple of examples:
 
 scsi\:0\:abc is a local file scsi:0:abc
 http\://myweb is a local file by name http://myweb
 file:scsi:0:abc is a local file scsi:0:abc
 file:http://myweb is a local file by name http://myweb
 
 fat:c:\path\to\dir\:floppy\:  is a fat file by name \path\to\dir:floppy:
 NOTE:The above example cannot be expressed using the file: protocol.
 
 
 Changelog w.r.t to iteration 0:
1) removes flexibility added to nbd semantics  eg -- nbd:\::
2) introduce the file: protocol to indicate local file
 
 Changelog w.r.t to iteration 1:
1) generically handles 'file:' protocol in find_protocol
2) centralizes 'filename' pruning before the call to open().
3) fixes buffer overflow seen in fill_token()
4) adheres to codying style
5) patch against upstream qemu tree
 
 Changelog w.r.t to iteration 2:
1) really really fixes buffer overflow seen in 
   fill_token() (if not, beat me :)
2) the centralized 'filename' pruning had a side effect with
   qcow2 files and other files. Fixed it. _open() is back.
 
 Changelog w.r.t to iteration 3:
1) support added to raw-win32.c (i do not have the setup to 
   test this change. Request help with testing)
2) ability to espace option-values containing commas using 
   backslashes 
   eg  file=file:abc,,  can also be expressed as file=file:abc\, 
   where 'abc,' is a filename
3) fixes a bug (reported by Jan Kiszka) w.r.t support for -snapshot

Yep, that's fixed in this version.

4) renamed _open() to qemu_open() and removed dependency on PATH_MAX
 
 Changelog w.r.t to iteration 4:
1) applies to upstream qemu and qemu-kvm tree

 
 Signed-off-by: Ram Pai linux...@us.ibm.com
 
 
  block.c   |   30 +++-
  block/raw-posix.c |   35 ++
  block/raw-win32.c |   26 --
  block/vvfat.c |   97 
 -
  cutils.c  |   26 +
  qemu-common.h |1 +
  qemu-option.c |8 -
  8 files changed, 185 insertions(+), 38 deletions(-)
 
 diff --git a/block.c b/block.c

...

 @@ -359,25 +351,15 @@ int bdrv_open2(BlockDriverState *bs, const char 
 *filename, int flags,
  }
  total_size = bdrv_getlength(bs1)  SECTOR_BITS;
  
 -if (bs1-drv  bs1-drv-protocol_name)
 -is_protocol = 1;
 -
  bdrv_delete(bs1);
  
  get_tmp_filename(tmp_filename, sizeof(tmp_filename));
  
 -/* Real path is meaningless for protocols */
 -if (is_protocol)
 -snprintf(backing_filename, sizeof(backing_filename),
 - %s, filename);
 -else
 -realpath(filename, backing_filename);
 -

This removes realpath without any replacement, right? Did you verify
that this doesn't break anything, namely snapshots with relative paths
for the backing image? Please check commit a817d93 and provide a
reasoning why it's safe to drop it.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
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] Add a kvm subtest -- pci_hotplug, which supports both Windows OS and Linux OS.

[Yaniv Kaul]

On 7/15/2009 6:49 AM, Yolkfull Chow wrote:

This is a subtest in kvm. It will verify newly added pci block device now. For 
Windows support,it needs to use_telnet since 'wmic' which is used to check disk 
info could only be executed in telnet session not ssh. Just ran it on guest 
Fedora-11.32 and Windows2008.32, both passed:

# ./scan_results.py
teststatus  seconds 
info
--  --- 

Fedora.11.32.nic_hotplug.nic_rtl8139GOOD68  
completed successfully
Fedora.11.32.nic_hotplug.nic_virtio GOOD46  
completed successfully
Fedora.11.32.block_hotplug.fmt_qcow2.block_virtio   GOOD46  
completed successfully
Fedora.11.32.block_hotplug.fmt_qcow2.block_scsi GOOD44  
completed successfully
Fedora.11.32.block_hotplug.fmt_raw.block_virtio GOOD45  
completed successfully
Fedora.11.32.block_hotplug.fmt_raw.block_scsi   GOOD46  
completed successfully
Win2008.32.nic_hotplug.nic_rtl8139  GOOD66  
completed successfully
Win2008.32.block_hotplug.fmt_qcow2.block_scsi   GOOD186 
completed successfully
Win2008.32.block_hotplug.fmt_raw.block_scsi GOOD71  
completed successfully
   

- Can you add virtio-net and virtio-blk to Windows 2008 as well?
- Where are you formating the disk on Windows?
- You need to check in virtio-net - that the adapter can send/receive 
traffic after hot-plugging; in virtio-blk - that you can read from / 
write to the disk.


Thanks,
Y.




Signed-off-by: Yolkfull Chowyz...@redhat.com
---
  client/tests/kvm/kvm.py   |1 +
  client/tests/kvm/kvm_tests.cfg.sample |   69 +++-
  client/tests/kvm/kvm_tests.py |   98 +
  client/tests/kvm/kvm_vm.py|2 +
  4 files changed, 169 insertions(+), 1 deletions(-)

diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py
index b18b643..fc92e10 100644
--- a/client/tests/kvm/kvm.py
+++ b/client/tests/kvm/kvm.py
@@ -55,6 +55,7 @@ class kvm(test.test):
  kvm_install:  test_routine(kvm_install, 
run_kvm_install),
  linux_s3: test_routine(kvm_tests, run_linux_s3),
  stress_boot:  test_routine(kvm_tests, run_stress_boot),
+pci_hotplug:  test_routine(kvm_tests, run_pci_hotplug),
  }

  # Make it possible to import modules from the test's bindir
diff --git a/client/tests/kvm/kvm_tests.cfg.sample 
b/client/tests/kvm/kvm_tests.cfg.sample
index 2f864de..7ec6f72 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -91,9 +91,56 @@ variants:

  - stress_boot:
  type = stress_boot
-max_vms = 5
+max_vms = 5
  alive_test_cmd = ps aux

+
+- nic_hotplug:
+type = pci_hotplug
+pci_type = nic
+modprobe_acpiphp = yes
+reference_cmd = lspci
+find_pci_cmd = 'lspci | tail -n1'
+pci_test_cmd = 'nslookup www.redhat.com'
+seconds_wait_for_device_install = 3
+variants:
+- nic_8139:
+pci_model = rtl8139
+match_string = 8139
+- nic_virtio:
+pci_model = virtio
+match_string = Virtio network device
+- nic_e1000:
+pci_model = e1000
+match_string = Gigabit Ethernet Controller
+
+- block_hotplug:
+type = pci_hotplug
+pci_type = block
+modprobe_acpiphp = yes
+reference_cmd = lspci
+find_pci_cmd = 'lspci | tail -n1'
+images +=  stg
+boot_drive_stg = no
+image_name_stg = storage
+image_size = 1G
+force_create_image_stg = yes
+seconds_wait_for_device_install = 3
+pci_test_cmd = 'yes|mke2fs `fdisk -l 21 |grep '/dev/[sv]d[a-z] 
doesn' | awk '{print $2}'`'
+variants:
+- block_virtio:
+pci_model = virtio
+match_string = Virtio block device
+- block_scsi:
+pci_model = scsi
+match_string = SCSI
+variants:
+- fmt_qcow2:
+image_format_stg = qcow2
+- fmt_raw:
+image_format_stg = raw
+
+
  # NICs
  variants:
  - @rtl8139:
@@ -119,6 +166,10 @@ variants:
  - Fedora:
  no setup
  ssh_prompt = \[r...@.{0,50}][\#\$] 
+nic_hotplug:
+modprobe_acpiphp = no
+block_hotplug:
+modprobe_acpiphp = no

  variants:
  - 8.32:
@@ -306,6 +357,22 @@ variants:
  

Problem with Grub and KVM 88

[Erik Wartusch]

Hi all,

Following problem.
I recently upgraded kvm from 7.2 (Debian Lenny repository version) to
the newest 88 KVM.

Since then when I first started and stopped a Debian Lenny virtual
instance (guest) at the next (second) start I get the following error:
Grub loading, please wait. Error 2. So the first time its booting
the second not, resulting with this error. 

KVM Version 88
Kernel Host system: 2.6.26-2-amd64
Kernel guest system: 2.6.26-2-amd64
CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
OS for host and guest: Debian Lenny

Qemu command line from a script:
#!/bin/sh

/usr/local/kvm/bin/qemu-system-x86_64 -m 256  \
  -name test3 \
  -boot c \
  -hda /var/kvm/test3.img \
  -net nic,macaddr=00:30:1c:45:35:04,model=virtio,vlan=0 \
  -net tap,script=/etc/kvm/kvm-ifup,vlan=0 \
  -k de \
  -vnc 192.168.125.21:4 \
  -monitor tcp:127.0.0.1:2024,server,nowait \
  -serial none \
  -parallel none \
  -daemonize  /dev/null 21

A CentOS or Windows XP are working fine.

Can somebody confirm this or any solution?
Kind Regards,
Erik

--
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: Problem with Grub and KVM 88

[Alexey Eromenko]

- Erik Wartusch e.wartu...@mitacs.com wrote:

 Hi all,
 
 Following problem.
 I recently upgraded kvm from 7.2 (Debian Lenny repository version) to
 the newest 88 KVM.
 
 Since then when I first started and stopped a Debian Lenny virtual
 instance (guest) at the next (second) start I get the following
 error:
 Grub loading, please wait. Error 2. So the first time its
 booting
 the second not, resulting with this error. 
 

I have the Debian Lenny VM installer booting fine on KVM-88 (32 and 64-bit 
CD-ROM ISOs).
Host is RHEL 5.3/x64.
If you try if -no-kvm option, does it work?

-Alexey
--
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: [Autotest] [PATCH] Assign an UUID for each VM in kvm command line

[Dor Laor]

On 07/15/2009 12:12 PM, Yolkfull Chow wrote:

Would submit this patch which is from our internal kvm-autotest patches 
submitted by Jason.
So that we could go on test case about parameters verification(UUID, DMI data 
etc).

Signed-off-by: Yolkfull Chowyz...@redhat.com
---
  client/tests/kvm/kvm_vm.py |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
index 503f636..68cc235 100644
--- a/client/tests/kvm/kvm_vm.py
+++ b/client/tests/kvm/kvm_vm.py
@@ -287,6 +287,10 @@ class VM:
  elif params.get(display) == nographic:
  qemu_cmd +=  -nographic

+uuid = os.popen(cat /proc/sys/kernel/random/uuid).readline().strip()
+if uuid:
+qemu_cmd +=  -uuid %s % uuid


If you'll change the uuid on every run, the guest will notice that. Some 
guest (M$) might not love it.
Why not use a static uuid or even just test uuid in a specific test 
without having it in all tests?


btw: why you're at it, please add uuid to the block devices too.
+ the -smbios option.

Thanks,
dor


+
  return qemu_cmd




--
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: [Autotest] [RFC] KVM-Autotest: remote shell utility for Windows guests

[Lucas Meneghel Rodrigues]

On Wed, Jul 8, 2009 at 4:46 AM, Michael Goldishmgold...@redhat.com wrote:
 I'm resending the message because it probably got filtered out due to the
 attached setup.bat file.

 The contents of setup.bat were:

 copy D:\rss.exe C:\

 net user Administrator /active:yes
 net user Administrator 1q2w3eP
 netsh firewall set opmode disable

 reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v Remote Shell 
 Server /d C:\rss.exe 22 /t REG_SZ /f
 reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon /v 
 AutoAdminLogon /d 1 /t REG_SZ /f
 reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon /v 
 DefaultUserName /d Administrator /t REG_SZ /f
 reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon /v 
 DefaultPassword /d 1q2w3eP /t REG_SZ /f

 - Original Message -

 Hi,

 In an attempt to solve the SSH problems we have with Windows, I wrote a little
 remote shell utility to replace the OpenSSH server we're currently using with
 Win(2000|XP|2003) and the builtin Telnet server we're using with Win2008.
 It also works with Vista, for which we currently have no other solution.

This is a very welcome addition to our test tools, for sure.


 Features:
 - Listens on a requested port (22 by default).
 - Provides clients with a cmd.exe shell.
 - Multiple clients can connect simultaneously.
 - Uses no authentication whatsoever.
 - Uses standard API calls that should work on all modern Windows variants.
 - Displays an informative message box if any API call fails.
 - Automatically closes all processes started by a client when it disconnects.
 - Allows clients to run GUI programs (see comment below).
 - Starts minimized by default so it doesn't interfere with step file tests.
 - Reports all activity in a text box.
 - The code is short (450 lines including comments).

I definitely like that :)


 Tested and verified to work on WinXP 32, 2003 32, Vista 32 and 64, 2008 32.
 I haven't tested it on other Windows versions but it should work (should be
 interesting to test it on Windows 7).

 The source code is attached.  I used MinGW (with Code::Blocks) to compile it
 under WinXP.  Link it with ws2_32.lib.  If anyone wants the binary please let
 me know and I'll send it somehow (I don't know if I'm supposed to send
 binaries to the list).


 Problems:
 - cmd.exe echoes back the command line sent to it.  This means commands are
 echoed twice: first by the local terminal and then by the remote cmd.exe.
 So if you send ver\r\n to the server you get:
 ver\r\nver\r\nMicrosoft Windows [Version ...]\r\nC:\\
 In order for it to work with Autotest we'll have to make some modifications
 to kvm_utils.kvm_spawn (which should be replaced by kvm_subprocess anyway) --
 specifically disable the local terminal echo, and not assume that the command
 line is echoed exactly once (it may not be echoed at all by Linux guests).

 - The server does not send or receive files.  For now we can transfer files
 into Windows guests using ISOs (-cdrom).  If it turns out to be necessary, 
 file
 send/receive support can be implemented into the shell server, or we can use 
 an
 open source Windows FTP server or find some other solution.

Yes, a remote copy utility would be good, in order to keep consistency.

 - Running GUI apps: Vista and 2008 seem to run GUI apps just fine from a 
 remote
 shell, but in older Windows versions you must use cmd /c
 (e.g. cmd /c notepad).

 To be compatible with all Windows versions, Windows GUI tests should probably
 always use cmd /c to run GUI apps.  There's no need to use it for console
 commands (e.g. dir).

 Note that when using cmd /c the command returns only when the GUI app exits.
 Without cmd /c the command returns immediately.

 - Some interactive console programs don't behave nicely when their output is
 redirected (to a remote client in this case).  One example is the builtin
 ftp.exe.  If you want to use it, you should do so without waiting for
 interactive output from the program, which means you should just send the FTP
 commands one by one and hope everything works, and finally send a 'quit'
 command to get back to cmd.exe.


 Installation on guests:
 The following should be done as a superuser:
 - Copy the program to the guest (C:\ should be fine).
 - Disable the firewall.
 - Enable the Administrator account.
 - Make Windows logon automatically using the Administrator account.
 - Make the server program run automatically on startup.

 I'm attaching a setup.bat file that does the above.
 setup.bat and rss.exe should be packaged together in an ISO and sent to the
 guest with -cdrom.  Note that setup.bat assumes that rss.exe is in D:\.
 This will not be true if we run the guest with multiple hard drives, so we'll
 have to do something about that.


 Please send me comments if you have any.  If you think this isn't a proper
 solution, or if you can suggest a better one, please let me know.

So far we have your utility, STAF (sugested by Yaniv) and *possibly*

Problem with Grub and KVM 88

[Erik Wartusch]

- Erik Wartusch e.wartusch at mitacs.com wrote:

 Hi all,
 
 Following problem.
 I recently upgraded kvm from 7.2 (Debian Lenny repository version) to
 the newest 88 KVM.
 
 Since then when I first started and stopped a Debian Lenny virtual
 instance (guest) at the next (second) start I get the following
 error:
 Grub loading, please wait. Error 2. So the first time its
 booting
 the second not, resulting with this error. 
 

I've tried the option -no-kvm. Same problem. Booting from ISOs is not the 
problem. I have images which I used with the 72 version without any problem 
and now with 88 they don't boot the second time.

Erik

 I have the Debian Lenny VM installer booting fine on KVM-88 (32 and 64-bit 
 CD-ROM ISOs).
 Host is RHEL 5.3/x64.
 If you try if -no-kvm option, does it work?

 -Alexey
 --

--
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

Fix migration issue when the destination is loaded

[Dor Laor]

 From abbe3b57af6a28bb81e5fb8b09b10802a8ccc3fe Mon Sep 17 00:00:00 2001
From: Dor Laor d...@redhat.com
Date: Wed, 15 Jul 2009 17:53:16 +0300
Subject: [PATCH] Fix migration issue when the destination is loaded

If the migration socket is full, we get EAGAIN for the write.
The set_fd_handler2 defers the write for later on. The function
tries to wake up the iothread by qemu_kvm_notify_work.
Since this happens in a loop, multiple times, the pipe that emulates eventfd
becomes full and we get a deadlock.

It is solved by checking for write-readiness using select.
Note that I check for select only for full 8 byte write and not
for partial writes. This is because we'll break the reader otherwise.

Signed-off-by: Dor Laor d...@redhat.com
---
 qemu-kvm.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/qemu-kvm.c b/qemu-kvm.c
index ed7e466..0ea67a7 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2094,12 +2094,28 @@ void qemu_kvm_notify_work(void)
 uint64_t value = 1;
 char buffer[8];
 size_t offset = 0;
+fd_set wfds;
+struct timeval tv;
+int retval;
 
 if (io_thread_fd == -1)
return;
 
 memcpy(buffer, value, sizeof(value));
 
+FD_ZERO(wfds);
+FD_SET(io_thread_fd, wfds);
+tv.tv_sec = tv.tv_usec = 0;
+retval = select(io_thread_fd + 1, NULL, wfds, NULL, tv);
+if (retval == -1) {
+fprintf(stderr, failed to notify io thread due to select error\n);
+return;
+} else if (retval == 0)
+/* We probably ponded this pipe too much and it is full now */
+return;
+
+assert(FD_ISSET(io_thread_fd, wfds));
+
 while (offset  8) {
ssize_t len;
 
-- 
1.6.2.5

Re: [Qemu-devel] [PATCH] rev5: support colon in filenames

[Blue Swirl]

On 7/15/09, Ram Pai linux...@us.ibm.com wrote:
 Problem: It is impossible to feed filenames with the character colon because
  qemu interprets such names as a protocol. For example filename scsi:0, is
  interpreted as a protocol by name scsi.

  --- a/block/raw-posix.c
  +++ b/block/raw-posix.c
  +static int qemu_open(const char *filename, int flags, ...)

  --- a/block/raw-win32.c
  +++ b/block/raw-win32.c
  +fd = qemu_open(filename, O_WRONLY | O_CREAT | O_TRUNC | O_BINARY,

I bet this won't compile on win32.

Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda filename with
funky characters like ',' ':'  '!'
--
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: Problem with Grub and KVM 88

[Erik Wartusch]

I've reinstalled Debian Lenny now on a fresh virtual harddisk and now
its working... Seems like my old images I used with 72 are the problem
with 88.

Erik

Am Mittwoch, den 15.07.2009, 16:20 +0200 schrieb Erik Wartusch:
 - Erik Wartusch e.wartusch at mitacs.com wrote:
 
  Hi all,
  
  Following problem.
  I recently upgraded kvm from 7.2 (Debian Lenny repository version) to
  the newest 88 KVM.
  
  Since then when I first started and stopped a Debian Lenny virtual
  instance (guest) at the next (second) start I get the following
  error:
  Grub loading, please wait. Error 2. So the first time its
  booting
  the second not, resulting with this error. 
  
 
 I've tried the option -no-kvm. Same problem. Booting from ISOs is not the 
 problem. I have images which I used with the 72 version without any problem 
 and now with 88 they don't boot the second time.
 
 Erik
 
  I have the Debian Lenny VM installer booting fine on KVM-88 (32 and 64-bit 
  CD-ROM ISOs).
  Host is RHEL 5.3/x64.
  If you try if -no-kvm option, does it work?
 
  -Alexey
  --


--
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: Problem with Grub and KVM 88

[Brian Jackson]

On Wednesday 15 July 2009 06:06:54 am Erik Wartusch wrote:
 Hi all,

 Following problem.
 I recently upgraded kvm from 7.2 (Debian Lenny repository version) to
 the newest 88 KVM.


How did you install kvm-88? Did you do a proper install? including the bios 
files, extboot, etc?

--Iggy



 Since then when I first started and stopped a Debian Lenny virtual
 instance (guest) at the next (second) start I get the following error:
 Grub loading, please wait. Error 2. So the first time its booting
 the second not, resulting with this error.

 KVM Version 88
 Kernel Host system: 2.6.26-2-amd64
 Kernel guest system: 2.6.26-2-amd64
 CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
 OS for host and guest: Debian Lenny

 Qemu command line from a script:
 #!/bin/sh

 /usr/local/kvm/bin/qemu-system-x86_64 -m 256  \
   -name test3 \
   -boot c \
   -hda /var/kvm/test3.img \
   -net nic,macaddr=00:30:1c:45:35:04,model=virtio,vlan=0 \
   -net tap,script=/etc/kvm/kvm-ifup,vlan=0 \
   -k de \
   -vnc 192.168.125.21:4 \
   -monitor tcp:127.0.0.1:2024,server,nowait \
   -serial none \
   -parallel none \
   -daemonize  /dev/null 21

 A CentOS or Windows XP are working fine.

 Can somebody confirm this or any solution?
 Kind Regards,
 Erik

 --
 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
--
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] rev5: support colon in filenames

[Anthony Liguori]

Blue Swirl wrote:

I bet this won't compile on win32.

Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda filename with
funky characters like ',' ':'  '!'
  


-drive name=hda,if=ide,cache=off -hda foo.img
-drive name=vda,if=virtio,cache=writeback -vda foo.img
-drive name=sdb,if=scsi,unit=1 -sdb boo.img

But Paul has long objected to having -vda or -sda syntaxes.  I do agree 
though that the most sane thing to do is to make the filename an 
independent argument.


--
Regards,

Anthony Liguori

--
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: [Autotest] [RFC] KVM-Autotest: remote shell utility for Windows guests

[Michael Goldish]

- Lucas Meneghel Rodrigues l...@redhat.com wrote:

 On Wed, Jul 8, 2009 at 4:46 AM, Michael Goldishmgold...@redhat.com
 wrote:
  I'm resending the message because it probably got filtered out due
 to the
  attached setup.bat file.
 
  The contents of setup.bat were:
 
  copy D:\rss.exe C:\
 
  net user Administrator /active:yes
  net user Administrator 1q2w3eP
  netsh firewall set opmode disable
 
  reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v
 Remote Shell Server /d C:\rss.exe 22 /t REG_SZ /f
  reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon
 /v AutoAdminLogon /d 1 /t REG_SZ /f
  reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon
 /v DefaultUserName /d Administrator /t REG_SZ /f
  reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon
 /v DefaultPassword /d 1q2w3eP /t REG_SZ /f
 
  - Original Message -
 
  Hi,
 
  In an attempt to solve the SSH problems we have with Windows, I
 wrote a little
  remote shell utility to replace the OpenSSH server we're currently
 using with
  Win(2000|XP|2003) and the builtin Telnet server we're using with
 Win2008.
  It also works with Vista, for which we currently have no other
 solution.
 
 This is a very welcome addition to our test tools, for sure.
 
 
  Features:
  - Listens on a requested port (22 by default).
  - Provides clients with a cmd.exe shell.
  - Multiple clients can connect simultaneously.
  - Uses no authentication whatsoever.
  - Uses standard API calls that should work on all modern Windows
 variants.
  - Displays an informative message box if any API call fails.
  - Automatically closes all processes started by a client when it
 disconnects.
  - Allows clients to run GUI programs (see comment below).
  - Starts minimized by default so it doesn't interfere with step file
 tests.
  - Reports all activity in a text box.
  - The code is short (450 lines including comments).
 
 I definitely like that :)
 
 
  Tested and verified to work on WinXP 32, 2003 32, Vista 32 and 64,
 2008 32.
  I haven't tested it on other Windows versions but it should work
 (should be
  interesting to test it on Windows 7).
 
  The source code is attached.  I used MinGW (with Code::Blocks) to
 compile it
  under WinXP.  Link it with ws2_32.lib.  If anyone wants the binary
 please let
  me know and I'll send it somehow (I don't know if I'm supposed to
 send
  binaries to the list).
 
 
  Problems:
  - cmd.exe echoes back the command line sent to it.  This means
 commands are
  echoed twice: first by the local terminal and then by the remote
 cmd.exe.
  So if you send ver\r\n to the server you get:
  ver\r\nver\r\nMicrosoft Windows [Version ...]\r\nC:\\
  In order for it to work with Autotest we'll have to make some
 modifications
  to kvm_utils.kvm_spawn (which should be replaced by kvm_subprocess
 anyway) --
  specifically disable the local terminal echo, and not assume that
 the command
  line is echoed exactly once (it may not be echoed at all by Linux
 guests).
 
  - The server does not send or receive files.  For now we can
 transfer files
  into Windows guests using ISOs (-cdrom).  If it turns out to be
 necessary, file
  send/receive support can be implemented into the shell server, or we
 can use an
  open source Windows FTP server or find some other solution.
 
 Yes, a remote copy utility would be good, in order to keep
 consistency.
 
  - Running GUI apps: Vista and 2008 seem to run GUI apps just fine
 from a remote
  shell, but in older Windows versions you must use cmd /c
  (e.g. cmd /c notepad).
 
  To be compatible with all Windows versions, Windows GUI tests should
 probably
  always use cmd /c to run GUI apps.  There's no need to use it for
 console
  commands (e.g. dir).
 
  Note that when using cmd /c the command returns only when the GUI
 app exits.
  Without cmd /c the command returns immediately.
 
  - Some interactive console programs don't behave nicely when their
 output is
  redirected (to a remote client in this case).  One example is the
 builtin
  ftp.exe.  If you want to use it, you should do so without waiting
 for
  interactive output from the program, which means you should just
 send the FTP
  commands one by one and hope everything works, and finally send a
 'quit'
  command to get back to cmd.exe.
 
 
  Installation on guests:
  The following should be done as a superuser:
  - Copy the program to the guest (C:\ should be fine).
  - Disable the firewall.
  - Enable the Administrator account.
  - Make Windows logon automatically using the Administrator account.
  - Make the server program run automatically on startup.
 
  I'm attaching a setup.bat file that does the above.
  setup.bat and rss.exe should be packaged together in an ISO and sent
 to the
  guest with -cdrom.  Note that setup.bat assumes that rss.exe is in
 D:\.
  This will not be true if we run the guest with multiple hard drives,
 so we'll
  have to do something about that.
 
 
  Please send me comments if 

Re: Problem with Grub and KVM 88

[Erik Wartusch]

I downloaded the tar.gz
http://downloads.sourceforge.net/sourceforge/kvm/kvm-88.tar.gz?use_mirror=dfn

unzipped it and followed the procedure according to the how to:
./configure --prefix=/usr/local/kvm 
make 
make install 
modprobe kvm-intel 

Erik

Am Mittwoch, den 15.07.2009, 10:11 -0500 schrieb Brian Jackson:
 On Wednesday 15 July 2009 06:06:54 am Erik Wartusch wrote:
  Hi all,
 
  Following problem.
  I recently upgraded kvm from 7.2 (Debian Lenny repository version) to
  the newest 88 KVM.
 
 
 How did you install kvm-88? Did you do a proper install? including the bios 
 files, extboot, etc?
 
 --Iggy
 
 
 
  Since then when I first started and stopped a Debian Lenny virtual
  instance (guest) at the next (second) start I get the following error:
  Grub loading, please wait. Error 2. So the first time its booting
  the second not, resulting with this error.
 
  KVM Version 88
  Kernel Host system: 2.6.26-2-amd64
  Kernel guest system: 2.6.26-2-amd64
  CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
  OS for host and guest: Debian Lenny
 
  Qemu command line from a script:
  #!/bin/sh
 
  /usr/local/kvm/bin/qemu-system-x86_64 -m 256  \
-name test3 \
-boot c \
-hda /var/kvm/test3.img \
-net nic,macaddr=00:30:1c:45:35:04,model=virtio,vlan=0 \
-net tap,script=/etc/kvm/kvm-ifup,vlan=0 \
-k de \
-vnc 192.168.125.21:4 \
-monitor tcp:127.0.0.1:2024,server,nowait \
-serial none \
-parallel none \
-daemonize  /dev/null 21
 
  A CentOS or Windows XP are working fine.
 
  Can somebody confirm this or any solution?
  Kind Regards,
  Erik
 
  --
  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
Mit freundlichen Grüßen
Erik Wartusch

-- 
CONNECTING PEOPLE AROUND THE WORLD ... http://www.mitacs.com
MITACS Telekomservice GesmbH Mail: e.wartu...@mitacs.com
Handelskai 388/543   Tel: +43 1 27900-273
A-1020 Wien  Fax: +43 1 27900-900

UID: ATU 52944907
Firmenbuch-Nummer: FN 213330X


--
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] rev5: support colon in filenames

[Blue Swirl]

On 7/15/09, Anthony Liguori aligu...@us.ibm.com wrote:
 Blue Swirl wrote:

  I bet this won't compile on win32.
 
  Instead of this (IMHO doomed) escape approach, maybe the filename
  parameter could be specified as the next argument, for example:
  -hda format=qcow2,blah,blah,filename_is_next_arg -hda
 filename with
  funky characters like ',' ':'  '!'
 
 

  -drive name=hda,if=ide,cache=off -hda foo.img
  -drive name=vda,if=virtio,cache=writeback -vda foo.img
  -drive name=sdb,if=scsi,unit=1 -sdb boo.img

  But Paul has long objected to having -vda or -sda syntaxes.  I do agree
 though that the most sane thing to do is to make the filename an independent
 argument.

Then how about something like:
 -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
 -drive name=vda,if=virtio,cache=writeback,file_comes_next  -patharg  foo.img
 -drive name=sdb,if=scsi,unit=1,fnarg -fnarg boo.img
--
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] rev5: support colon in filenames

[Anthony Liguori]

Kevin Wolf wrote:

Anthony Liguori schrieb:
  

Blue Swirl wrote:


I bet this won't compile on win32.

Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda filename with
funky characters like ',' ':'  '!'
  
  

-drive name=hda,if=ide,cache=off -hda foo.img
-drive name=vda,if=virtio,cache=writeback -vda foo.img
-drive name=sdb,if=scsi,unit=1 -sdb boo.img



So the names would need to be out of some reserved namespace like hdX,
sdX and vdX only? Or can I choose freely and call my disks net and
vnc and have them conflict with the respective existing options?
  


Yup, bad suggestion on my part.  See my next suggestion.


Also, when discussing the syntax, don't forget that there also is
-usbdevice disk: which would need to be changed in some way, too.

Kevin
  



--
Regards,

Anthony Liguori

--
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] rev5: support colon in filenames

[Anthony Liguori]

Blue Swirl wrote:

Then how about something like:
 -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
 -drive name=vda,if=virtio,cache=writeback,file_comes_next  -patharg  foo.img
 -drive name=sdb,if=scsi,unit=1,fnarg -fnarg boo.img
  


The explicit ordering part seems clunky to me.  How about:

-drive name=vda,if=virtio -drive.vda.file filename.img

What's nice about this syntax is it generalizes well.  You could have:

-drive.vda.if virtio -drive.vda.file filename.img
-net nic,model=rtl8139,name=foo -net.foo.macaddr 00:11:43:55:44:22

--
Regards,

Anthony Liguori

--
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] rev5: support colon in filenames

[Paul Brook]

On Wednesday 15 July 2009, Anthony Liguori wrote:
 Blue Swirl wrote:
  I bet this won't compile on win32.
 
  Instead of this (IMHO doomed) escape approach, maybe the filename
  parameter could be specified as the next argument, for example:
  -hda format=qcow2,blah,blah,filename_is_next_arg -hda filename with
  funky characters like ',' ':'  '!'

 -drive name=hda,if=ide,cache=off -hda foo.img
 -drive name=vda,if=virtio,cache=writeback -vda foo.img
 -drive name=sdb,if=scsi,unit=1 -sdb boo.img

 But Paul has long objected to having -vda or -sda syntaxes.  I do agree
 though that the most sane thing to do is to make the filename an
 independent argument.

I dislike implicit ordering of arguments even less. Having -foo -bar behave 
differently to -bar -foo is bad. We already have this a bit for things like 
-net, but splitting something into two as a parsing hack seems really lame.

How about -drive args=whatever,unparsed_name=bah

Where unparsed_name is defined to be the last argument, and blah is 
interpreted literally.

Paul
--
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

KVM 88 Boot from Floppy Stops

[Adam Barrett]

I have tested and confirmed that in KVM-86 all worked fine.

I attempted to test in KVM-87, however I was not able to finish
install due to make errors
KVM-87 configure: http://pastebin.ca/1495900
KVM-87 make: http://pastebin.ca/1495902

In KVM-88 I am able to install again, but I am not able to get past
the boot from floppy in the BIOS:

I am booting a native Windows installation (raw harddrive) from a
virtual bootdisk. Here is how I start KVM:
utahcon:$ /usr/local/kvm/bin/qemu-system-x86_64 -hda /dev/sda -fda
/var/virtual/bootdisk.img -m 1024 -boot a

Finally this is where it stops:
http://utahcon.com/images/qemu/Screenshot-QEMU.png

BTW - I have removed and added kvm/kvm-intel to my modprobe as well.
--
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] rev5: support colon in filenames

[Gerd Hoffmann]

On 07/15/09 17:14, Anthony Liguori wrote:

Blue Swirl wrote:

I bet this won't compile on win32.

Instead of this (IMHO doomed) escape approach, maybe the filename
parameter could be specified as the next argument, for example:
-hda format=qcow2,blah,blah,filename_is_next_arg -hda filename with
funky characters like ',' ':'  '!'


-drive name=hda,if=ide,cache=off -hda foo.img
-drive name=vda,if=virtio,cache=writeback -vda foo.img
-drive name=sdb,if=scsi,unit=1 -sdb boo.img

But Paul has long objected to having -vda or -sda syntaxes. I do agree
though that the most sane thing to do is to make the filename an
independent argument.


Jumping in here as I'm looking into this from the qdev-ifying point of 
view ;)


I'd like to move to a model where -drive adds host-side state only and
the actual disks are added via -device, i.e. something like

  -drive if=none,name=foo,file=/path/to/file
  -device virtio-blk-pci,drive=foo

Instead of using '-drive if=none' we could use some other syntax where 
the filename can be passed as separate argument.  Can switches have two 
arguments?  If so, maybe this:


  -hostdrive $file $options

comments?

cheers,
  Gerd
--
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] rev5: support colon in filenames

[Paul Brook]

 Instead of using '-drive if=none' we could use some other syntax where
 the filename can be passed as separate argument.  Can switches have two
 arguments?  If so, maybe this:

-hostdrive $file $options

This only works for a single mandatory argument that needs to contain awkward 
characters.

Paul
--
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 1/5] remove kvm types from handle unhandled

[Glauber Costa]

I'm in an ongoing process of not using kvm-specific types in function
declarations. handle_unhandled() is the first victim. Since we don't
really use this data, but just the reason, remove them entirely.

Signed-off-by: Glauber Costa glom...@redhat.com
---
 qemu-kvm.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/qemu-kvm.c b/qemu-kvm.c
index 355adf4..904e751 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -176,8 +176,7 @@ int kvm_mmio_write(void *opaque, uint64_t addr, uint8_t 
*data, int len)
return 0;
 }
 
-static int handle_unhandled(kvm_context_t kvm, kvm_vcpu_context_t vcpu,
-uint64_t reason)
+static int handle_unhandled(uint64_t reason)
 {
 fprintf(stderr, kvm: unhandled exit %PRIx64\n, reason);
 return -EINVAL;
@@ -1085,12 +1084,10 @@ again:
if (1) {
switch (run-exit_reason) {
case KVM_EXIT_UNKNOWN:
-   r = handle_unhandled(kvm, vcpu,
-   run-hw.hardware_exit_reason);
+   r = handle_unhandled(run-hw.hardware_exit_reason);
break;
case KVM_EXIT_FAIL_ENTRY:
-   r = handle_unhandled(kvm, vcpu,
-   run-fail_entry.hardware_entry_failure_reason);
+   r = 
handle_unhandled(run-fail_entry.hardware_entry_failure_reason);
break;
case KVM_EXIT_EXCEPTION:
fprintf(stderr, exception %d (%x)\n,
-- 
1.6.2.2

--
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 0/5] Further cleanups

[Glauber Costa]

Hi guys,

I'm sending a series that moves further in reusing upstream code

Here I'm reusing kvm_vm_ioctl, kvm_ioctl, kvm_check_extension and
the cpuid bits for i386.

--
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 2/5] reuse kvm_vm_ioctl

[Glauber Costa]

Start using kvm_vm_ioctl's code.
For type safety, delete vm_fd from kvm_context entirely, so the
compiler can play along with us helping to detect errors I might
have made.

Signed-off-by: Glauber Costa glom...@redhat.com
---
 kvm-all.c  |2 ++
 qemu-kvm-x86.c |   18 +-
 qemu-kvm.c |   52 ++--
 qemu-kvm.h |6 +++---
 4 files changed, 40 insertions(+), 38 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 67908a7..9373d99 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -809,6 +809,7 @@ int kvm_ioctl(KVMState *s, int type, ...)
 
 return ret;
 }
+#endif
 
 int kvm_vm_ioctl(KVMState *s, int type, ...)
 {
@@ -827,6 +828,7 @@ int kvm_vm_ioctl(KVMState *s, int type, ...)
 return ret;
 }
 
+#ifdef KVM_UPSTREAM
 int kvm_vcpu_ioctl(CPUState *env, int type, ...)
 {
 int ret;
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 350f272..c7393cd 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -40,7 +40,7 @@ int kvm_set_tss_addr(kvm_context_t kvm, unsigned long addr)
 
r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
if (r  0) {
-   r = ioctl(kvm-vm_fd, KVM_SET_TSS_ADDR, addr);
+   r = kvm_vm_ioctl(kvm_state, KVM_SET_TSS_ADDR, addr);
if (r == -1) {
fprintf(stderr, kvm_set_tss_addr: %m\n);
return -errno;
@@ -82,7 +82,7 @@ static int kvm_create_pit(kvm_context_t kvm)
if (!kvm-no_pit_creation) {
r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_PIT);
if (r  0) {
-   r = ioctl(kvm-vm_fd, KVM_CREATE_PIT);
+   r = kvm_vm_ioctl(kvm_state, KVM_CREATE_PIT);
if (r = 0)
kvm-pit_in_kernel = 1;
else {
@@ -211,7 +211,7 @@ int kvm_create_memory_alias(kvm_context_t kvm,
.memory_size = len,
.target_phys_addr = target_phys,
};
-   int fd = kvm-vm_fd;
+   int fd = kvm_state-vmfd;
int r;
int slot;
 
@@ -272,7 +272,7 @@ int kvm_get_pit(kvm_context_t kvm, struct kvm_pit_state *s)
int r;
if (!kvm-pit_in_kernel)
return 0;
-   r = ioctl(kvm-vm_fd, KVM_GET_PIT, s);
+   r = kvm_vm_ioctl(kvm_state, KVM_GET_PIT, s);
if (r == -1) {
r = -errno;
perror(kvm_get_pit);
@@ -285,7 +285,7 @@ int kvm_set_pit(kvm_context_t kvm, struct kvm_pit_state *s)
int r;
if (!kvm-pit_in_kernel)
return 0;
-   r = ioctl(kvm-vm_fd, KVM_SET_PIT, s);
+   r = kvm_vm_ioctl(kvm_state, KVM_SET_PIT, s);
if (r == -1) {
r = -errno;
perror(kvm_set_pit);
@@ -299,7 +299,7 @@ int kvm_get_pit2(kvm_context_t kvm, struct kvm_pit_state2 
*ps2)
int r;
if (!kvm-pit_in_kernel)
return 0;
-   r = ioctl(kvm-vm_fd, KVM_GET_PIT2, ps2);
+   r = kvm_vm_ioctl(kvm_state, KVM_GET_PIT2, ps2);
if (r == -1) {
r = -errno;
perror(kvm_get_pit2);
@@ -312,7 +312,7 @@ int kvm_set_pit2(kvm_context_t kvm, struct kvm_pit_state2 
*ps2)
int r;
if (!kvm-pit_in_kernel)
return 0;
-   r = ioctl(kvm-vm_fd, KVM_SET_PIT2, ps2);
+   r = kvm_vm_ioctl(kvm_state, KVM_SET_PIT2, ps2);
if (r == -1) {
r = -errno;
perror(kvm_set_pit2);
@@ -549,7 +549,7 @@ int kvm_set_shadow_pages(kvm_context_t kvm, unsigned int 
nrshadow_pages)
r = ioctl(kvm-fd, KVM_CHECK_EXTENSION,
  KVM_CAP_MMU_SHADOW_CACHE_CONTROL);
if (r  0) {
-   r = ioctl(kvm-vm_fd, KVM_SET_NR_MMU_PAGES, nrshadow_pages);
+   r = kvm_vm_ioctl(kvm_state, KVM_SET_NR_MMU_PAGES, 
nrshadow_pages);
if (r == -1) {
fprintf(stderr, kvm_set_shadow_pages: %m\n);
return -errno;
@@ -568,7 +568,7 @@ int kvm_get_shadow_pages(kvm_context_t kvm, unsigned int 
*nrshadow_pages)
r = ioctl(kvm-fd, KVM_CHECK_EXTENSION,
  KVM_CAP_MMU_SHADOW_CACHE_CONTROL);
if (r  0) {
-   *nrshadow_pages = ioctl(kvm-vm_fd, KVM_GET_NR_MMU_PAGES);
+   *nrshadow_pages = kvm_vm_ioctl(kvm_state, KVM_GET_NR_MMU_PAGES);
return 0;
}
 #endif
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 904e751..f09bcca 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -44,7 +44,7 @@ int kvm_pit_reinject = 1;
 int kvm_nested = 0;
 
 
-static KVMState *kvm_state;
+KVMState *kvm_state;
 kvm_context_t kvm_context;
 
 pthread_mutex_t qemu_mutex = PTHREAD_MUTEX_INITIALIZER;
@@ -332,7 +332,7 @@ static int kvm_dirty_pages_log_change(kvm_context_t kvm,
mem.guest_phys_addr,
mem.memory_size,
mem.flags);
-   r = ioctl(kvm-vm_fd, 

[PATCH 3/5] reuse kvm_ioctl

[Glauber Costa]

Start using kvm_ioctl's code.
For type safety, delete fd from kvm_context entirely, so the
compiler can play along with us helping to detect errors I might
have made.

Signed-off-by: Glauber Costa glom...@redhat.com
---
 kvm-all.c  |2 +-
 qemu-kvm-x86.c |   18 +-
 qemu-kvm.c |   32 
 qemu-kvm.h |3 +--
 4 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 9373d99..0ec6475 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -793,6 +793,7 @@ void kvm_set_phys_mem(target_phys_addr_t start_addr,
 }
 }
 
+#endif
 int kvm_ioctl(KVMState *s, int type, ...)
 {
 int ret;
@@ -809,7 +810,6 @@ int kvm_ioctl(KVMState *s, int type, ...)
 
 return ret;
 }
-#endif
 
 int kvm_vm_ioctl(KVMState *s, int type, ...)
 {
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index c7393cd..fb3ac9a 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -38,7 +38,7 @@ int kvm_set_tss_addr(kvm_context_t kvm, unsigned long addr)
 #ifdef KVM_CAP_SET_TSS_ADDR
int r;
 
-   r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
+   r = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
if (r  0) {
r = kvm_vm_ioctl(kvm_state, KVM_SET_TSS_ADDR, addr);
if (r == -1) {
@@ -56,7 +56,7 @@ static int kvm_init_tss(kvm_context_t kvm)
 #ifdef KVM_CAP_SET_TSS_ADDR
int r;
 
-   r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
+   r = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
if (r  0) {
/*
 * this address is 3 pages before the bios, and the bios should 
present
@@ -80,7 +80,7 @@ static int kvm_create_pit(kvm_context_t kvm)
 
kvm-pit_in_kernel = 0;
if (!kvm-no_pit_creation) {
-   r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_PIT);
+   r = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, KVM_CAP_PIT);
if (r  0) {
r = kvm_vm_ioctl(kvm_state, KVM_CREATE_PIT);
if (r = 0)
@@ -384,7 +384,7 @@ struct kvm_msr_list *kvm_get_msr_list(kvm_context_t kvm)
int r, e;
 
sizer.nmsrs = 0;
-   r = ioctl(kvm-fd, KVM_GET_MSR_INDEX_LIST, sizer);
+   r = kvm_ioctl(kvm_state, KVM_GET_MSR_INDEX_LIST, sizer);
if (r == -1  errno != E2BIG)
return NULL;
/* Old kernel modules had a bug and could write beyond the provided
@@ -393,7 +393,7 @@ struct kvm_msr_list *kvm_get_msr_list(kvm_context_t kvm)
   sizer.nmsrs * sizeof(*msrs-indices)));
 
msrs-nmsrs = sizer.nmsrs;
-   r = ioctl(kvm-fd, KVM_GET_MSR_INDEX_LIST, msrs);
+   r = kvm_ioctl(kvm_state, KVM_GET_MSR_INDEX_LIST, msrs);
if (r == -1) {
e = errno;
free(msrs);
@@ -546,7 +546,7 @@ int kvm_set_shadow_pages(kvm_context_t kvm, unsigned int 
nrshadow_pages)
 #ifdef KVM_CAP_MMU_SHADOW_CACHE_CONTROL
int r;
 
-   r = ioctl(kvm-fd, KVM_CHECK_EXTENSION,
+   r = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION,
  KVM_CAP_MMU_SHADOW_CACHE_CONTROL);
if (r  0) {
r = kvm_vm_ioctl(kvm_state, KVM_SET_NR_MMU_PAGES, 
nrshadow_pages);
@@ -565,7 +565,7 @@ int kvm_get_shadow_pages(kvm_context_t kvm, unsigned int 
*nrshadow_pages)
 #ifdef KVM_CAP_MMU_SHADOW_CACHE_CONTROL
int r;
 
-   r = ioctl(kvm-fd, KVM_CHECK_EXTENSION,
+   r = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION,
  KVM_CAP_MMU_SHADOW_CACHE_CONTROL);
if (r  0) {
*nrshadow_pages = kvm_vm_ioctl(kvm_state, KVM_GET_NR_MMU_PAGES);
@@ -584,7 +584,7 @@ static int tpr_access_reporting(kvm_vcpu_context_t vcpu, 
int enabled)
.enabled = enabled,
};
 
-   r = ioctl(vcpu-kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_VAPIC);
+   r = ioctl(kvm_state-fd, KVM_CHECK_EXTENSION, KVM_CAP_VAPIC);
if (r == -1 || r == 0)
return -ENOSYS;
r = ioctl(vcpu-fd, KVM_TPR_ACCESS_REPORTING, tac);
@@ -618,7 +618,7 @@ static struct kvm_cpuid2 *try_get_cpuid(kvm_context_t kvm, 
int max)
size = sizeof(*cpuid) + max * sizeof(*cpuid-entries);
cpuid = qemu_malloc(size);
cpuid-nent = max;
-   r = ioctl(kvm-fd, KVM_GET_SUPPORTED_CPUID, cpuid);
+   r = kvm_ioctl(kvm_state, KVM_GET_SUPPORTED_CPUID, cpuid);
if (r == -1)
r = -errno;
else if (r == 0  cpuid-nent = max)
diff --git a/qemu-kvm.c b/qemu-kvm.c
index f09bcca..2654f91 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -227,7 +227,7 @@ static int get_free_slot(kvm_context_t kvm)
int tss_ext;
 
 #if defined(KVM_CAP_SET_TSS_ADDR)  !defined(__s390__)
-   tss_ext = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
+   tss_ext = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, 
KVM_CAP_SET_TSS_ADDR);
 #else
tss_ext = 0;
 #endif
@@ -451,7 +451,7 @@ 

[PATCH 5/5] use upstream cpuid code

[Glauber Costa]

use cpuid code from upstream. By doing that, we lose the following snippet
in kvm_get_supported_cpuid():

ret |= 1  12; /* MTRR */
ret |= 1  16; /* PAT */
ret |= 1  7;  /* MCE */
ret |= 1  14; /* MCA */

A quick search in mailing lists says this code is not really necessary, and 
we're
keeping it just for backwards compatibility. This is not that important, because
we'd lose it anyway in the golden day in which we totally merge with qemu.
Anyway, if it do _is_ important, we can send a patch to qemu with it.

Signed-off-by: Glauber Costa glom...@redhat.com
---
 qemu-kvm-x86.c|  121 -
 target-i386/kvm.c |2 +
 2 files changed, 2 insertions(+), 121 deletions(-)

diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 128a792..8d6a6a8 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -608,108 +608,6 @@ int kvm_disable_tpr_access_reporting(kvm_vcpu_context_t 
vcpu)
 
 #endif
 
-#ifdef KVM_CAP_EXT_CPUID
-
-static struct kvm_cpuid2 *try_get_cpuid(kvm_context_t kvm, int max)
-{
-   struct kvm_cpuid2 *cpuid;
-   int r, size;
-
-   size = sizeof(*cpuid) + max * sizeof(*cpuid-entries);
-   cpuid = qemu_malloc(size);
-   cpuid-nent = max;
-   r = kvm_ioctl(kvm_state, KVM_GET_SUPPORTED_CPUID, cpuid);
-   if (r == -1)
-   r = -errno;
-   else if (r == 0  cpuid-nent = max)
-   r = -E2BIG;
-   if (r  0) {
-   if (r == -E2BIG) {
-   free(cpuid);
-   return NULL;
-   } else {
-   fprintf(stderr, KVM_GET_SUPPORTED_CPUID failed: %s\n,
-   strerror(-r));
-   exit(1);
-   }
-   }
-   return cpuid;
-}
-
-#define R_EAX 0
-#define R_ECX 1
-#define R_EDX 2
-#define R_EBX 3
-#define R_ESP 4
-#define R_EBP 5
-#define R_ESI 6
-#define R_EDI 7
-
-uint32_t kvm_get_supported_cpuid(kvm_context_t kvm, uint32_t function, int reg)
-{
-   struct kvm_cpuid2 *cpuid;
-   int i, max;
-   uint32_t ret = 0;
-   uint32_t cpuid_1_edx;
-
-   if (!kvm_check_extension(kvm_state, KVM_CAP_EXT_CPUID)) {
-   return -1U;
-   }
-
-   max = 1;
-   while ((cpuid = try_get_cpuid(kvm, max)) == NULL) {
-   max *= 2;
-   }
-
-   for (i = 0; i  cpuid-nent; ++i) {
-   if (cpuid-entries[i].function == function) {
-   switch (reg) {
-   case R_EAX:
-   ret = cpuid-entries[i].eax;
-   break;
-   case R_EBX:
-   ret = cpuid-entries[i].ebx;
-   break;
-   case R_ECX:
-   ret = cpuid-entries[i].ecx;
-   break;
-   case R_EDX:
-   ret = cpuid-entries[i].edx;
-if (function == 1) {
-/* kvm misreports the following features
- */
-ret |= 1  12; /* MTRR */
-ret |= 1  16; /* PAT */
-ret |= 1  7;  /* MCE */
-ret |= 1  14; /* MCA */
-}
-
-   /* On Intel, kvm returns cpuid according to
-* the Intel spec, so add missing bits
-* according to the AMD spec:
-*/
-   if (function == 0x8001) {
-   cpuid_1_edx = 
kvm_get_supported_cpuid(kvm, 1, R_EDX);
-   ret |= cpuid_1_edx  0xdfeff7ff;
-   }
-   break;
-   }
-   }
-   }
-
-   free(cpuid);
-
-   return ret;
-}
-
-#else
-
-uint32_t kvm_get_supported_cpuid(kvm_context_t kvm, uint32_t function, int reg)
-{
-   return -1U;
-}
-
-#endif
 int kvm_qemu_create_memory_alias(uint64_t phys_start,
  uint64_t len,
  uint64_t target_phys)
@@ -1191,19 +1089,6 @@ static int get_para_features(kvm_context_t kvm_context)
return features;
 }
 
-static void kvm_trim_features(uint32_t *features, uint32_t supported)
-{
-int i;
-uint32_t mask;
-
-for (i = 0; i  32; ++i) {
-mask = 1U  i;
-if ((*features  mask)  !(supported  mask)) {
-*features = ~mask;
-}
-}
-}
-
 int kvm_arch_qemu_init_env(CPUState *cenv)
 {
 struct kvm_cpuid_entry2 cpuid_ent[100];
@@ -1599,12 +1484,6 @@ int kvm_arch_init_irq_routing(void)
 return 0;
 }
 
-uint32_t kvm_arch_get_supported_cpuid(CPUState *env, uint32_t 

[PATCH 4/5] check extension

[Glauber Costa]

use upstream check_extension code

Signed-off-by: Glauber Costa glom...@redhat.com
---
 hw/device-assignment.c |2 +-
 kvm-all.c  |2 ++
 qemu-kvm-x86.c |6 +++---
 qemu-kvm.c |   18 --
 qemu-kvm.h |2 +-
 5 files changed, 11 insertions(+), 19 deletions(-)

diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 88c3baf..75db546 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -639,7 +639,7 @@ static int assign_device(AssignedDevInfo *adev)
 /* We always enable the IOMMU if present
  * (or when not disabled on the command line)
  */
-r = kvm_check_extension(kvm_context, KVM_CAP_IOMMU);
+r = kvm_check_extension(kvm_state, KVM_CAP_IOMMU);
 if (r  !adev-disable_iommu)
assigned_dev_data.flags |= KVM_DEV_ASSIGN_ENABLE_IOMMU;
 #endif
diff --git a/kvm-all.c b/kvm-all.c
index 0ec6475..b4b5a35 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -383,6 +383,7 @@ int kvm_uncoalesce_mmio_region(target_phys_addr_t start, 
ram_addr_t size)
 return ret;
 }
 
+#endif
 int kvm_check_extension(KVMState *s, unsigned int extension)
 {
 int ret;
@@ -394,6 +395,7 @@ int kvm_check_extension(KVMState *s, unsigned int extension)
 
 return ret;
 }
+#ifdef KVM_UPSTREAM
 
 int kvm_init(int smp_cpus)
 {
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index fb3ac9a..128a792 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -328,7 +328,7 @@ int kvm_has_pit_state2(kvm_context_t kvm)
int r = 0;
 
 #ifdef KVM_CAP_PIT_STATE2
-   r = kvm_check_extension(kvm, KVM_CAP_PIT_STATE2);
+   r = kvm_check_extension(kvm_state, KVM_CAP_PIT_STATE2);
 #endif
return r;
 }
@@ -652,7 +652,7 @@ uint32_t kvm_get_supported_cpuid(kvm_context_t kvm, 
uint32_t function, int reg)
uint32_t ret = 0;
uint32_t cpuid_1_edx;
 
-   if (!kvm_check_extension(kvm, KVM_CAP_EXT_CPUID)) {
+   if (!kvm_check_extension(kvm_state, KVM_CAP_EXT_CPUID)) {
return -1U;
}
 
@@ -1184,7 +1184,7 @@ static int get_para_features(kvm_context_t kvm_context)
int i, features = 0;
 
for (i = 0; i  ARRAY_SIZE(para_features)-1; i++) {
-   if (kvm_check_extension(kvm_context, para_features[i].cap))
+   if (kvm_check_extension(kvm_state, para_features[i].cap))
features |= (1  para_features[i].feature);
}
 
diff --git a/qemu-kvm.c b/qemu-kvm.c
index 2654f91..d5f8464 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -590,16 +590,6 @@ static int kvm_create_default_phys_mem(kvm_context_t kvm,
return -1;
 }
 
-int kvm_check_extension(kvm_context_t kvm, int ext)
-{
-   int ret;
-
-   ret = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, ext);
-   if (ret  0)
-   return ret;
-   return 0;
-}
-
 void kvm_create_irqchip(kvm_context_t kvm)
 {
int r;
@@ -1378,7 +1368,7 @@ int kvm_has_gsi_routing(kvm_context_t kvm)
 int r = 0;
 
 #ifdef KVM_CAP_IRQ_ROUTING
-r = kvm_check_extension(kvm, KVM_CAP_IRQ_ROUTING);
+r = kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING);
 #endif
 return r;
 }
@@ -1386,7 +1376,7 @@ int kvm_has_gsi_routing(kvm_context_t kvm)
 int kvm_get_gsi_count(kvm_context_t kvm)
 {
 #ifdef KVM_CAP_IRQ_ROUTING
-   return kvm_check_extension(kvm, KVM_CAP_IRQ_ROUTING);
+   return kvm_check_extension(kvm_state, KVM_CAP_IRQ_ROUTING);
 #else
return -EINVAL;
 #endif
@@ -1660,7 +1650,7 @@ int kvm_irqfd(kvm_context_t kvm, int gsi, int flags)
int r;
int fd;
 
-   if (!kvm_check_extension(kvm, KVM_CAP_IRQFD))
+   if (!kvm_check_extension(kvm_state, KVM_CAP_IRQFD))
return -ENOENT;
 
fd = eventfd(0, 0);
@@ -2431,7 +2421,7 @@ int kvm_setup_guest_memory(void *area, unsigned long size)
 
 int kvm_qemu_check_extension(int ext)
 {
-return kvm_check_extension(kvm_context, ext);
+return kvm_check_extension(kvm_state, ext);
 }
 
 int kvm_qemu_init_env(CPUState *cenv)
diff --git a/qemu-kvm.h b/qemu-kvm.h
index a6261fd..afb6fef 100644
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -163,7 +163,6 @@ int kvm_create(kvm_context_t kvm,
   unsigned long phys_mem_bytes,
   void **phys_mem);
 int kvm_create_vm(kvm_context_t kvm);
-int kvm_check_extension(kvm_context_t kvm, int ext);
 void kvm_create_irqchip(kvm_context_t kvm);
 
 /*!
@@ -1179,5 +1178,6 @@ extern KVMState *kvm_state;
 
 int kvm_ioctl(KVMState *s, int type, ...);
 int kvm_vm_ioctl(KVMState *s, int type, ...);
+int kvm_check_extension(KVMState *s, unsigned int ext);
 
 #endif
-- 
1.6.2.2

--
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] rev5: support colon in filenames

[Kevin Wolf]

Anthony Liguori schrieb:
 Blue Swirl wrote:
 Then how about something like:
  -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
  -drive name=vda,if=virtio,cache=writeback,file_comes_next  -patharg  foo.img
  -drive name=sdb,if=scsi,unit=1,fnarg -fnarg boo.img
   
 
 The explicit ordering part seems clunky to me.  How about:
 
 -drive name=vda,if=virtio -drive.vda.file filename.img
 
 What's nice about this syntax is it generalizes well.  You could have:
 
 -drive.vda.if virtio -drive.vda.file filename.img
 -net nic,model=rtl8139,name=foo -net.foo.macaddr 00:11:43:55:44:22

Looks like a very verbose syntax. However, it's the cleanest suggestion
so far, IMHO. It might be perfectly reasonable to use for management
apps or for a single option (the file name) manually as needed. We'll
need to retain the old, more convenient syntax anyway for compatibility.
Your examples are mixed style already, so this is probably what you
intended anyway.

Kevin
--
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] rev5: support colon in filenames

[Ram Pai]

On Wed, 2009-07-15 at 11:30 +0200, Jan Kiszka wrote:
 Ram Pai wrote:
  Problem: It is impossible to feed filenames with the character colon because
  qemu interprets such names as a protocol. For example filename scsi:0, is
  interpreted as a protocol by name scsi.
  
  This patch allows user to espace colon characters. For example the above
  filename can now be expressed either as 'scsi\:0' or as file:scsi:0
  
  anything following the file: tag is interpreted verbatin. However if 
  file:
  tag is omitted then any colon characters in the string must be escaped using
  backslash.
  
  Here are couple of examples:
  
  scsi\:0\:abc is a local file scsi:0:abc
  http\://myweb is a local file by name http://myweb
  file:scsi:0:abc is a local file scsi:0:abc
  file:http://myweb is a local file by name http://myweb
  
  fat:c:\path\to\dir\:floppy\:  is a fat file by name \path\to\dir:floppy:
  NOTE:The above example cannot be expressed using the file: protocol.
  
  
  Changelog w.r.t to iteration 0:
 1) removes flexibility added to nbd semantics  eg -- nbd:\::
 2) introduce the file: protocol to indicate local file
  
  Changelog w.r.t to iteration 1:
 1) generically handles 'file:' protocol in find_protocol
 2) centralizes 'filename' pruning before the call to open().
 3) fixes buffer overflow seen in fill_token()
 4) adheres to codying style
 5) patch against upstream qemu tree
  
  Changelog w.r.t to iteration 2:
 1) really really fixes buffer overflow seen in 
  fill_token() (if not, beat me :)
 2) the centralized 'filename' pruning had a side effect with
  qcow2 files and other files. Fixed it. _open() is back.
  
  Changelog w.r.t to iteration 3:
 1) support added to raw-win32.c (i do not have the setup to 
  test this change. Request help with testing)
 2) ability to espace option-values containing commas using 
  backslashes 
  eg  file=file:abc,,  can also be expressed as file=file:abc\, 
  where 'abc,' is a filename
 3) fixes a bug (reported by Jan Kiszka) w.r.t support for -snapshot
 
 Yep, that's fixed in this version.
 
 4) renamed _open() to qemu_open() and removed dependency on PATH_MAX
  
  Changelog w.r.t to iteration 4:
 1) applies to upstream qemu and qemu-kvm tree
 
  
  Signed-off-by: Ram Pai linux...@us.ibm.com
  
  
   block.c   |   30 +++-
   block/raw-posix.c |   35 ++
   block/raw-win32.c |   26 --
   block/vvfat.c |   97 
  -
   cutils.c  |   26 +
   qemu-common.h |1 +
   qemu-option.c |8 -
   8 files changed, 185 insertions(+), 38 deletions(-)
  
  diff --git a/block.c b/block.c
 
 ...
 
  @@ -359,25 +351,15 @@ int bdrv_open2(BlockDriverState *bs, const char 
  *filename, int flags,
   }
   total_size = bdrv_getlength(bs1)  SECTOR_BITS;
   
  -if (bs1-drv  bs1-drv-protocol_name)
  -is_protocol = 1;
  -
   bdrv_delete(bs1);
   
   get_tmp_filename(tmp_filename, sizeof(tmp_filename));
   
  -/* Real path is meaningless for protocols */
  -if (is_protocol)
  -snprintf(backing_filename, sizeof(backing_filename),
  - %s, filename);
  -else
  -realpath(filename, backing_filename);
  -
 
 This removes realpath without any replacement, right? Did you verify
 that this doesn't break anything, namely snapshots with relative paths
 for the backing image? Please check commit a817d93 and provide a
 reasoning why it's safe to drop it.

I have verified with relative paths and it works.

After analyzing the code, i came to the conclusion that call to
realpath()  adds no real value. 

The logic in bdrv_open2() is something like this

bdrv_open2()
{
   if (snapshot) {
 backup = realpath(filename);
 filename=generate_a_temp_file();
   }
   drv=parse_and_get_bdrv(filename);
   drv-bdrv_open(filename);
   if (backup) {
 bdrv_open2(backup);
   }
}
  
in the above function, the call to realpath() would have been useful had
it changed the current working directory before calling
bdrv_open2(backup). It does not. If in case any function within
drv-bdrv_open change the cwd, then I expect them to restore before
returning.

Also drv-bdrv_open() can anyway handle relative paths. 

Hence I conclude that the call to realpath() adds no value.

Do you see a flaw in this logic? 

RP
 
 Jan
 


--
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] rev5: support colon in filenames

[Michael S. Tsirkin]

On Wed, Jul 15, 2009 at 10:40:37AM -0500, Anthony Liguori wrote:
 Blue Swirl wrote:
 Then how about something like:
  -drive name=hda,if=ide,cache=off,file_is_arg -filearg foo.img
  -drive name=vda,if=virtio,cache=writeback,file_comes_next  -patharg  foo.img
  -drive name=sdb,if=scsi,unit=1,fnarg -fnarg boo.img
   

 The explicit ordering part seems clunky to me.  How about:

 -drive name=vda,if=virtio -drive.vda.file filename.img

 What's nice about this syntax is it generalizes well.  You could have:

 -drive.vda.if virtio -drive.vda.file filename.img
 -net nic,model=rtl8139,name=foo -net.foo.macaddr 00:11:43:55:44:22

nice.

--
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] Fix non-KVM build

[Michael S. Tsirkin]

On Wed, Jun 24, 2009 at 01:13:46PM -0500, Anthony Liguori wrote:
 This introduces some #ifdefs in pcspk to fix the build when KVM isn't enabled.
 
 Signed-off-by: Anthony Liguori aligu...@us.ibm.com
 ---
  hw/pcspk.c |   15 +--
  1 files changed, 9 insertions(+), 6 deletions(-)
 
 diff --git a/hw/pcspk.c b/hw/pcspk.c
 index 9e1b59a..236995a 100644
 --- a/hw/pcspk.c
 +++ b/hw/pcspk.c
 @@ -80,11 +80,6 @@ static void kvm_set_pit_ch2(PITState *pit,
  kvm_set_pit(kvm_context, inkernel_state);
  }
  }
 -#else
 -static inline void kvm_get_pit_ch2(PITState *pit,
 -   kvm_pit_state *inkernel_state) { }
 -static inline void kvm_set_pit_ch2(PITState *pit,
 -   kvm_pit_state *inkernel_state) { }
  #endif
  

The version with stubs looks cleaner to me. IMO we really should be
moving away from ifdefs for features, and only use them for
compiler-specific things.  If for no other reason, then because it
increases the common code that is compiled for all platforms,
decreasing the chance that people submit a patch that does not
build on soe platform.

Is the issue with struct kvm_pit_state?
Can't we just stub it out as well?

struct kvm_pit_state {};

  static inline void generate_samples(PCSpkState *s)
 @@ -111,7 +106,9 @@ static void pcspk_callback(void *opaque, int free)
  PCSpkState *s = opaque;
  unsigned int n;
  
 +#ifdef USE_KVM_PIT
  kvm_get_pit_ch2(s-pit, NULL);
 +#endif
  
  if (pit_get_mode(s-pit, 2) != 3)
  return;
 @@ -158,7 +155,9 @@ static uint32_t pcspk_ioport_read(void *opaque, uint32_t 
 addr)
  PCSpkState *s = opaque;
  int out;
  
 +#ifdef USE_KVM_PIT
  kvm_get_pit_ch2(s-pit, NULL);
 +#endif
  
  s-dummy_refresh_clock ^= (1  4);
  out = pit_get_out(s-pit, 2, qemu_get_clock(vm_clock))  5;
 @@ -168,11 +167,13 @@ static uint32_t pcspk_ioport_read(void *opaque, 
 uint32_t addr)
  
  static void pcspk_ioport_write(void *opaque, uint32_t addr, uint32_t val)
  {
 -struct kvm_pit_state inkernel_state;
  PCSpkState *s = opaque;
  const int gate = val  1;
 +#ifdef USE_KVM_PIT
 +struct kvm_pit_state inkernel_state;
  
  kvm_get_pit_ch2(s-pit, inkernel_state);
 +#endif
  
  s-data_on = (val  1)  1;
  pit_set_gate(s-pit, 2, gate);
 @@ -182,7 +183,9 @@ static void pcspk_ioport_write(void *opaque, uint32_t 
 addr, uint32_t val)
  AUD_set_active_out(s-voice, gate  s-data_on);
  }
  
 +#ifdef USE_KVM_PIT
  kvm_set_pit_ch2(s-pit, inkernel_state);
 +#endif
  }
  
  void pcspk_init(PITState *pit)
 -- 
 1.6.2.5
 
 --
 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
--
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 08/10] Move IO APIC to its own lock.

[Marcelo Tosatti]

On Tue, Jul 14, 2009 at 05:30:43PM +0300, Gleb Natapov wrote:
 
 Signed-off-by: Gleb Natapov g...@redhat.com
 ---
  arch/ia64/kvm/kvm-ia64.c |   27 ++--
  arch/x86/kvm/lapic.c |5 +---
  arch/x86/kvm/x86.c   |   30 ++-
  virt/kvm/ioapic.c|   50 -
  virt/kvm/ioapic.h|1 +
  5 files changed, 73 insertions(+), 40 deletions(-)
 
 diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
 index 0ad09f0..dd7ef2d 100644
 --- a/arch/ia64/kvm/kvm-ia64.c
 +++ b/arch/ia64/kvm/kvm-ia64.c
 @@ -850,9 +850,16 @@ static int kvm_vm_ioctl_get_irqchip(struct kvm *kvm,
  
   r = 0;
   switch (chip-chip_id) {
 - case KVM_IRQCHIP_IOAPIC:
 - memcpy(chip-chip.ioapic, ioapic_irqchip(kvm),
 - sizeof(struct kvm_ioapic_state));
 + case KVM_IRQCHIP_IOAPIC: {
 + struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
 + if (ioapic) {
 + spin_lock(ioapic-lock);
 + memcpy(chip-chip.ioapic, ioapic,
 +sizeof(struct kvm_ioapic_state));
 + spin_unlock(ioapic-lock);
 + } else
 + r = -EINVAL;
 + }
   break;
   default:
   r = -EINVAL;
 @@ -867,10 +874,16 @@ static int kvm_vm_ioctl_set_irqchip(struct kvm *kvm, 
 struct kvm_irqchip *chip)
  
   r = 0;
   switch (chip-chip_id) {
 - case KVM_IRQCHIP_IOAPIC:
 - memcpy(ioapic_irqchip(kvm),
 - chip-chip.ioapic,
 - sizeof(struct kvm_ioapic_state));
 + case KVM_IRQCHIP_IOAPIC: {
 + struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
 + if (ioapic) {
 + spin_lock(ioapic-lock);
 + memcpy(ioapic, chip-chip.ioapic,
 +sizeof(struct kvm_ioapic_state));
 + spin_unlock(ioapic-lock);
 + } else
 + r = -EINVAL;
 + }
   break;
   default:
   r = -EINVAL;
 diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
 index e2e2849..61ffcfc 100644
 --- a/arch/x86/kvm/lapic.c
 +++ b/arch/x86/kvm/lapic.c
 @@ -471,11 +471,8 @@ static void apic_set_eoi(struct kvm_lapic *apic)
   trigger_mode = IOAPIC_LEVEL_TRIG;
   else
   trigger_mode = IOAPIC_EDGE_TRIG;
 - if (!(apic_get_reg(apic, APIC_SPIV)  APIC_SPIV_DIRECTED_EOI)) {
 - mutex_lock(apic-vcpu-kvm-irq_lock);
 + if (!(apic_get_reg(apic, APIC_SPIV)  APIC_SPIV_DIRECTED_EOI))
   kvm_ioapic_update_eoi(apic-vcpu-kvm, vector, trigger_mode);
 - mutex_unlock(apic-vcpu-kvm-irq_lock);
 - }
  }
  
  static void apic_send_ipi(struct kvm_lapic *apic)
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 48567fa..de99b84 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -2010,10 +2010,16 @@ static int kvm_vm_ioctl_get_irqchip(struct kvm *kvm, 
 struct kvm_irqchip *chip)
   pic_irqchip(kvm)-pics[1],
   sizeof(struct kvm_pic_state));
   break;
 - case KVM_IRQCHIP_IOAPIC:
 - memcpy(chip-chip.ioapic,
 - ioapic_irqchip(kvm),
 - sizeof(struct kvm_ioapic_state));
 + case KVM_IRQCHIP_IOAPIC: {
 + struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
 + if (ioapic) {
 + spin_lock(ioapic-lock);
 + memcpy(chip-chip.ioapic, ioapic,
 +sizeof(struct kvm_ioapic_state));
 + spin_unlock(ioapic-lock);
 + } else
 + r = -EINVAL;
 + }
   break;
   default:
   r = -EINVAL;
 @@ -2042,12 +2048,16 @@ static int kvm_vm_ioctl_set_irqchip(struct kvm *kvm, 
 struct kvm_irqchip *chip)
   sizeof(struct kvm_pic_state));
   spin_unlock(pic_irqchip(kvm)-lock);
   break;
 - case KVM_IRQCHIP_IOAPIC:
 - mutex_lock(kvm-irq_lock);
 - memcpy(ioapic_irqchip(kvm),
 - chip-chip.ioapic,
 - sizeof(struct kvm_ioapic_state));
 - mutex_unlock(kvm-irq_lock);
 + case KVM_IRQCHIP_IOAPIC: {
 + struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
 + if (ioapic) {
 + spin_lock(ioapic-lock);
 + memcpy(ioapic, chip-chip.ioapic,
 +sizeof(struct kvm_ioapic_state));
 + spin_unlock(ioapic-lock);
 + } else
 + r = -EINVAL;
 + }
   break;
   default:
   r = -EINVAL;
 diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
 index fa05f67..300ee3b 100644
 --- a/virt/kvm/ioapic.c
 +++ 

Re: [Qemu-devel] [PATCH] rev3: support colon in filenames

[Jamie Lokier]

Kevin Wolf wrote:
 Can we at least allow \, instead of ,, in parameter parsing, so that the
 backslash has the practical benefit of being a single universal escape
 character?

Is there a good reason why we cannot simply use \char to escape
_any_ character, in every context where a user-supplied
string/name/path/file is used?

I'm thinking of consistency here.  Instead of special cases for
filenames, why not a standard scheme for all the places in command
lines _and_ the monitor where a name/path/file is needed?

There are many examples where it would be useful if unusual characters
didn't break things, they simply worked.

Examples: -vnc unix: path, -net port: device path, -net script path,
-net sock= path, -net group= groupname, tap and bt device names.

\char is an obvious scheme to standardise on given QEMU's unix shell
heritage.  It would work equally well for command line options (which
are often comma-separated) and for monitor commands (which are often
space-separated).

It would have the nice property of being easy for management
programs/scripts to quote, without them having a special list of
characters to quote, without needing to update them if QEMU needs to
quote more characters in future for some reason.

Now, I see one significant hurdle with that: it's quite inconvenient
for Windows users, typing paths like c:\path\to\dir\file, if those
backslashes are stipped.

So I propose this as a universal quoting scheme:

\char where char is not ASCII alphanumeric.

Shell quoting is easy:

   qfile=`printf %s $file | sed 's/[^0-9a-zA-Z]//g'`

   qemu -drive file=$qfile,if=scsi,media=disk

Same quoting applied when sending the monitor a command to change a
CD-ROM file or add a USB disk, for example.

-- Jamie
--
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 10/10] Change irq routing table to use gsi indexed array.

[Marcelo Tosatti]

On Tue, Jul 14, 2009 at 05:30:45PM +0300, Gleb Natapov wrote:
 Use gsi indexed array instead of scanning all entries on each interrupt
 injection. Also maintain back mapping from irqchip/pin to gsi to speedup
 interrupt acknowledgment notifications.
 
 Signed-off-by: Gleb Natapov g...@redhat.com
 ---
  include/linux/kvm_host.h |   11 ++-
  virt/kvm/irq_comm.c  |   62 -
  2 files changed, 47 insertions(+), 26 deletions(-)
 
 diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
 index aa64d0d..ae6cbf1 100644
 --- a/include/linux/kvm_host.h
 +++ b/include/linux/kvm_host.h
 @@ -128,7 +128,14 @@ struct kvm_kernel_irq_routing_entry {
   } irqchip;
   struct msi_msg msi;
   };
 - struct list_head link;
 + struct hlist_node link;
 +};
 +
 +struct kvm_irq_routing_table {
 + int chip[3][KVM_IOAPIC_NUM_PINS];
 + struct kvm_kernel_irq_routing_entry *rt_entries;
 + u32 max_gsi;
 + struct hlist_head map[0];
  };
  
  struct kvm {
 @@ -165,7 +172,7 @@ struct kvm {
  #endif
  
  #ifdef CONFIG_HAVE_KVM_IRQCHIP
 - struct kvm_kernel_irq_routing_entry *irq_routing;
 + struct kvm_irq_routing_table *irq_routing;
   spinlock_t irq_routing_lock;
   struct hlist_head mask_notifier_list;
   struct hlist_head irq_ack_notifier_list;
 diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
 index c54a28b..da643d4 100644
 --- a/virt/kvm/irq_comm.c
 +++ b/virt/kvm/irq_comm.c
 @@ -125,6 +125,8 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, int 
 irq, int level)
   struct kvm_kernel_irq_routing_entry *e;
   unsigned long *irq_state, sig_level;
   int ret = -1;
 + struct kvm_irq_routing_table *irq_rt;
 + struct hlist_node *n;
  
   trace_kvm_set_irq(irq, level, irq_source_id);
  
 @@ -147,14 +149,13 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, int 
 irq, int level)
* writes to the unused one.
*/
   rcu_read_lock();
 - for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
 - if (e-gsi == irq) {
 - int r = e-set(e, kvm, sig_level);
 - if (r  0)
 - continue;
 + irq_rt = rcu_dereference(kvm-irq_routing);
 + hlist_for_each_entry(e, n, irq_rt-map[irq], link) {
 + int r = e-set(e, kvm, sig_level);
 + if (r  0)
 + continue;
  
 - ret = r + ((ret  0) ? 0 : ret);
 - }
 + ret = r + ((ret  0) ? 0 : ret);
   }
   rcu_read_unlock();
   return ret;
 @@ -162,21 +163,16 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, int 
 irq, int level)
  
  void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
  {
 - struct kvm_kernel_irq_routing_entry *e;
   struct kvm_irq_ack_notifier *kian;
   struct hlist_node *n;
 - unsigned gsi = pin;
 + unsigned gsi;
  
   trace_kvm_ack_irq(irqchip, pin);
  
   rcu_read_lock();
 - for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
 - if (e-irqchip.irqchip == irqchip 
 - e-irqchip.pin == pin) {
 - gsi = e-gsi;
 - break;
 - }
 - }
 + gsi = rcu_dereference(kvm-irq_routing)-chip[irqchip][pin];
 + if (gsi == -1)
 + gsi = pin;
  
   hlist_for_each_entry_rcu(kian, n, kvm-irq_ack_notifier_list, link)
   if (kian-gsi == gsi)
 @@ -277,7 +273,8 @@ void kvm_free_irq_routing(struct kvm *kvm)
   kfree(kvm-irq_routing);
  }
  
 -static int setup_routing_entry(struct kvm_kernel_irq_routing_entry *e,
 +static int setup_routing_entry(struct kvm_irq_routing_table *rt,
 +struct kvm_kernel_irq_routing_entry *e,
  const struct kvm_irq_routing_entry *ue)
  {
   int r = -EINVAL;
 @@ -303,6 +300,7 @@ static int setup_routing_entry(struct 
 kvm_kernel_irq_routing_entry *e,
   }
   e-irqchip.irqchip = ue-u.irqchip.irqchip;
   e-irqchip.pin = ue-u.irqchip.pin + delta;
 + rt-chip[ue-u.irqchip.irqchip][e-irqchip.pin] = ue-gsi;
   break;
   case KVM_IRQ_ROUTING_MSI:
   e-set = kvm_set_msi;
 @@ -313,6 +311,8 @@ static int setup_routing_entry(struct 
 kvm_kernel_irq_routing_entry *e,
   default:
   goto out;
   }
 +
 + hlist_add_head(e-link, rt-map[e-gsi]);
   r = 0;
  out:
   return r;
 @@ -324,23 +324,37 @@ int kvm_set_irq_routing(struct kvm *kvm,
   unsigned nr,
   unsigned flags)
  {
 - struct kvm_kernel_irq_routing_entry *new, *old;
 - unsigned i;
 + struct kvm_irq_routing_table *new, *old;
 + u32 i, j, max_gsi = 0;
   int r;
  
 - /* last elemet is left zeored and indicates the end of the array */
 - new = kzalloc(sizeof(*new) * (nr + 1), 

Re: [Qemu-devel] Re: [PATCH] rev5: support colon in filenames

[Jamie Lokier]

Ram Pai wrote:
 I have verified with relative paths and it works.
 
 After analyzing the code, i came to the conclusion that call to
 realpath()  adds no real value. 
 
 The logic in bdrv_open2() is something like this
 
 bdrv_open2()
 {
if (snapshot) {
  backup = realpath(filename);
  filename=generate_a_temp_file();
}
drv=parse_and_get_bdrv(filename);
drv-bdrv_open(filename);
if (backup) {
  bdrv_open2(backup);
}
 }
   
 in the above function, the call to realpath() would have been useful had
 it changed the current working directory before calling
 bdrv_open2(backup). It does not. If in case any function within
 drv-bdrv_open change the cwd, then I expect them to restore before
 returning.
 
 Also drv-bdrv_open() can anyway handle relative paths. 
 
 Hence I conclude that the call to realpath() adds no value.
 
 Do you see a flaw in this logic? 

I don't know about snapshot, but when a qcow2 file contains a relative
path to it's backing file, QEMU cannot simply open using that relative
path, because it's relative to the directory containing the qcow2 file,
not QEMU's current directory.

(That said, I find it quite annoying when renaming qcow2 files that
there's no easy way to rename their backing files, and it's even worse
when moving qcow2 files which refer to backing files in another
directory, and _especially_ when the qcow2 file contains an absolute
path to the backing file and you're asked to move it to another system
which doesn't have those directories.)

-- Jamie
--
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] Re: [PATCH] rev5: support colon in filenames

[Ram Pai]

On Wed, 2009-07-15 at 19:20 +0100, Jamie Lokier wrote:
 Ram Pai wrote:
  I have verified with relative paths and it works.
  
  After analyzing the code, i came to the conclusion that call to
  realpath()  adds no real value. 
  
  The logic in bdrv_open2() is something like this
  
  bdrv_open2()
  {
 if (snapshot) {
   backup = realpath(filename);
   filename=generate_a_temp_file();
 }
 drv=parse_and_get_bdrv(filename);
 drv-bdrv_open(filename);
 if (backup) {
   bdrv_open2(backup);
 }
  }

  in the above function, the call to realpath() would have been useful had
  it changed the current working directory before calling
  bdrv_open2(backup). It does not. If in case any function within
  drv-bdrv_open change the cwd, then I expect them to restore before
  returning.
  
  Also drv-bdrv_open() can anyway handle relative paths. 
  
  Hence I conclude that the call to realpath() adds no value.
  
  Do you see a flaw in this logic? 
 
 I don't know about snapshot, but when a qcow2 file contains a relative
 path to it's backing file, QEMU cannot simply open using that relative
 path, because it's relative to the directory containing the qcow2 file,
 not QEMU's current directory.

I have successfully verified qcow2 files. But then I may not be trying
out the exact thing that you are talking about. Can you give me a test 
case that I can verify. I am pretty sure that the patch would work.
However i have not accumulated enough flight time on qemu; so i can be
wrong :(

And one other thing. Let me know if there a test-suite that I can try
for regressions.

RP

 
 (That said, I find it quite annoying when renaming qcow2 files that
 there's no easy way to rename their backing files, and it's even worse
 when moving qcow2 files which refer to backing files in another
 directory, and _especially_ when the qcow2 file contains an absolute
 path to the backing file and you're asked to move it to another system
 which doesn't have those directories.)
 
 -- Jamie
-- 
Ram Pai
System X Device-Driver Enablement Lead
Linux Technology Center
Beaverton OR-97006
503-5783752 t/l 7753752
linux...@us.ibm.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: [PATCH] KVM: Discard unnecessary kvm_mmu_flush_tlb() in kvm_mmu_load()

[Marcelo Tosatti]

On Thu, Jul 09, 2009 at 05:00:42PM +0800, Sheng Yang wrote:
 set_cr3() should already cover the TLB flushing.
 
 Signed-off-by: Sheng Yang sh...@linux.intel.com
 ---
  arch/x86/kvm/mmu.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
 index 231d880..501c11e 100644
 --- a/arch/x86/kvm/mmu.c
 +++ b/arch/x86/kvm/mmu.c
 @@ -2349,8 +2349,8 @@ int kvm_mmu_load(struct kvm_vcpu *vcpu)
   spin_unlock(vcpu-kvm-mmu_lock);
   if (r)
   goto out;
 + /* set_cr3() should ensure TLB has been flushed */
   kvm_x86_ops-set_cr3(vcpu, vcpu-arch.mmu.root_hpa);
 - kvm_mmu_flush_tlb(vcpu);
  out:
   return r;
  }
 -- 
 1.5.4.5

Applied, thanks.

--
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: Broken Finnish keymap

[Marcelo Tosatti]

On Mon, Jul 13, 2009 at 12:59:28PM +0300, Anssi Kolehmainen wrote:
 Hi,
 
 When I run kvm-88 with -vnc and -k fi and try to press ' (apostrophe) in
 vnc window I get b in the guest. Strange enough, in SDL window
 everything seems to work just fine. 
 
 Anyhow, the fix is to remove second apostrophe line from
 pc-bios/keymaps/fi. Also there are few other wrong keys so maybe
 keymap should be regenerated? BTW, sv (swedish) keymap works just fine.
 (And why have two different layouts since Swedish and Finnish keyboards
 have same layout anyway).

Please send to qemu-de...@nongnu.org.

 
 --- pc-bios/keymaps/fi.org2009-07-13 12:39:15.0 +0300
 +++ pc-bios/keymaps/fi  2009-07-13 12:56:40.0 +0300
 @@ -62,3 +62,2 @@
  Aring 0x1a shift
 -dead_diaeresis 0x1a altgr
  dead_abovering 0x1a shift altgr
 @@ -81,3 +80,2 @@
  kra 0x25 altgr
 -ampersand 0x25 shift altgr
  lstroke 0x26 altgr
 @@ -100,6 +98,2 @@
  multiply 0x2b shift altgr
 -guillemotleft 0x2c altgr
 -less 0x2c shift altgr
 -guillemotright 0x2d altgr
 -greater 0x2d shift altgr
  copyright 0x2e altgr
 @@ -108,3 +102,2 @@
  rightdoublequotemark 0x30 altgr
 -apostrophe 0x30 shift altgr
  mu 0x32 altgr
 
 -- 
 Anssi Kolehmainen
 anssi.kolehmai...@iki.fi
 040-5085390
 --
 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
--
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 10/10] Change irq routing table to use gsi indexed array.

[Michael S. Tsirkin]

On Tue, Jul 14, 2009 at 05:30:45PM +0300, Gleb Natapov wrote:
 @@ -147,14 +149,13 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, int 
 irq, int level)
* writes to the unused one.
*/
   rcu_read_lock();
 - for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
 - if (e-gsi == irq) {
 - int r = e-set(e, kvm, sig_level);
 - if (r  0)
 - continue;
 + irq_rt = rcu_dereference(kvm-irq_routing);
 + hlist_for_each_entry(e, n, irq_rt-map[irq], link) {

Don't you need to range-check irq? E.g. with irqfd, gsi is
controlled by guest.

 + int r = e-set(e, kvm, sig_level);
 + if (r  0)
 + continue;
  
 - ret = r + ((ret  0) ? 0 : ret);
 - }
 + ret = r + ((ret  0) ? 0 : ret);
   }
   rcu_read_unlock();
   return ret;
 @@ -162,21 +163,16 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, int 
 irq, int level)
  
  void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
  {
 - struct kvm_kernel_irq_routing_entry *e;
   struct kvm_irq_ack_notifier *kian;
   struct hlist_node *n;
 - unsigned gsi = pin;
 + unsigned gsi;
  
   trace_kvm_ack_irq(irqchip, pin);
  
   rcu_read_lock();
 - for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
 - if (e-irqchip.irqchip == irqchip 
 - e-irqchip.pin == pin) {
 - gsi = e-gsi;
 - break;
 - }
 - }
 + gsi = rcu_dereference(kvm-irq_routing)-chip[irqchip][pin];

And possibly here as well. Can guest control pin?

 + if (gsi == -1)
 + gsi = pin;
  
   hlist_for_each_entry_rcu(kian, n, kvm-irq_ack_notifier_list, link)
   if (kian-gsi == gsi)
 @@ -277,7 +273,8 @@ void kvm_free_irq_routing(struct kvm *kvm)
   kfree(kvm-irq_routing);
  }
  
 -static int setup_routing_entry(struct kvm_kernel_irq_routing_entry *e,
 +static int setup_routing_entry(struct kvm_irq_routing_table *rt,
 +struct kvm_kernel_irq_routing_entry *e,
  const struct kvm_irq_routing_entry *ue)
  {
   int r = -EINVAL;
 @@ -303,6 +300,7 @@ static int setup_routing_entry(struct 
 kvm_kernel_irq_routing_entry *e,
   }
   e-irqchip.irqchip = ue-u.irqchip.irqchip;
   e-irqchip.pin = ue-u.irqchip.pin + delta;
 + rt-chip[ue-u.irqchip.irqchip][e-irqchip.pin] = ue-gsi;
   break;
   case KVM_IRQ_ROUTING_MSI:
   e-set = kvm_set_msi;
 @@ -313,6 +311,8 @@ static int setup_routing_entry(struct 
 kvm_kernel_irq_routing_entry *e,
   default:
   goto out;
   }
 +
 + hlist_add_head(e-link, rt-map[e-gsi]);
   r = 0;
  out:
   return r;
 @@ -324,23 +324,37 @@ int kvm_set_irq_routing(struct kvm *kvm,
   unsigned nr,
   unsigned flags)
  {
 - struct kvm_kernel_irq_routing_entry *new, *old;
 - unsigned i;
 + struct kvm_irq_routing_table *new, *old;
 + u32 i, j, max_gsi = 0;
   int r;
  
 - /* last elemet is left zeored and indicates the end of the array */
 - new = kzalloc(sizeof(*new) * (nr + 1), GFP_KERNEL);
 + for (i = 0; i  nr; ++i) {
 + if (ue[i].gsi = KVM_MAX_IRQ_ROUTES)
 + return -EINVAL;
 + max_gsi = max(max_gsi, ue[i].gsi);
 + }
 +
 + max_gsi += 1;
 +
 + new = kzalloc(sizeof(*new) + (max_gsi * sizeof(struct hlist_head)) +
 +   (nr * sizeof(struct kvm_kernel_irq_routing_entry)),
 +   GFP_KERNEL);
  
   if (!new)
   return -ENOMEM;
  
 + new-rt_entries = (void *)new-map[max_gsi];
 +
 + new-max_gsi = max_gsi;
 + for (i = 0; i  3; i++)
 + for (j = 0; j  KVM_IOAPIC_NUM_PINS; j++)
 + new-chip[i][j] = -1;
 +
   for (i = 0; i  nr; ++i) {
   r = -EINVAL;
 - if (ue-gsi = KVM_MAX_IRQ_ROUTES)
 - goto out;
   if (ue-flags)
   goto out;
 - r = setup_routing_entry(new + i, ue);
 + r = setup_routing_entry(new, new-rt_entries[i], ue);
   if (r)
   goto out;
   ++ue;
 -- 
 1.6.2.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
--
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

[PATCHv4] uio: add generic driver for PCI 2.3 devices

[Michael S. Tsirkin]

This adds a generic uio driver that can bind to any PCI device.  First
user will be virtualization where a qemu userspace process needs to give
guest OS access to the device.

Interrupts are handled using the Interrupt Disable bit in the PCI command
register and Interrupt Status bit in the PCI status register.  All devices
compliant to PCI 2.3 (circa 2002) and all compliant PCI Express devices should
support these bits.  Driver detects this support, and won't bind to devices
which do not support the Interrupt Disable Bit in the command register.

It's expected that more features of interest to virtualization will be
added to this driver in the future. Possibilities are: mmap for device
resources, MSI/MSI-X, eventfd (to interface with kvm), iommu.

Acked-by: Chris Wright chr...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---

Hans, Greg, please review and consider for upstream.

This is intended to solve the problem in virtualization that shared
interrupts do not work with assigned devices. Earlier versions of this
patch have circulated on k...@vger.

Changes since v1:
- some naming changes
- do a single read to get both command and status register
Changes since v2:
- remove irqcontrol: user can enable interrupts by
  writing command register directly
- don't claim resources as we don't support mmap yet,
  but note the intent to do so in the commit log
Changes since v3:
- minor driver version fix

 MAINTAINERS   |8 ++
 drivers/uio/Kconfig   |   10 ++
 drivers/uio/Makefile  |1 +
 drivers/uio/uio_pci_generic.c |  207 +
 include/linux/pci_regs.h  |1 +
 5 files changed, 227 insertions(+), 0 deletions(-)
 create mode 100644 drivers/uio/uio_pci_generic.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 18c3f0c..39c7207 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2538,6 +2538,14 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
 S: Maintained
 F: include/asm-generic
 
+GENERIC UIO DRIVER FOR PCI DEVICES
+P: Michael S. Tsirkin
+M: m...@redhat.com
+L: kvm@vger.kernel.org
+L: linux-ker...@vger.kernel.org
+S: Supported
+F: drivers/uio/uio_pci_generic.c
+
 GFS2 FILE SYSTEM
 P: Steven Whitehouse
 M: swhit...@redhat.com
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 7f86534..0f14c8e 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -89,4 +89,14 @@ config UIO_SERCOS3
 
  If you compile this as a module, it will be called uio_sercos3.
 
+config UIO_PCI_GENERIC
+   tristate Generic driver for PCI 2.3 and PCI Express cards
+   depends on PCI
+   default n
+   help
+ Generic driver that you can bind, dynamically, to any
+ PCI 2.3 compliant and PCI Express card. It is useful,
+ primarily, for virtualization scenarios.
+ If you compile this as a module, it will be called uio_pci_generic.
+
 endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 5c2586d..73b2e75 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_UIO_PDRV_GENIRQ)   += uio_pdrv_genirq.o
 obj-$(CONFIG_UIO_SMX)  += uio_smx.o
 obj-$(CONFIG_UIO_AEC)  += uio_aec.o
 obj-$(CONFIG_UIO_SERCOS3)  += uio_sercos3.o
+obj-$(CONFIG_UIO_PCI_GENERIC)  += uio_pci_generic.o
diff --git a/drivers/uio/uio_pci_generic.c b/drivers/uio/uio_pci_generic.c
new file mode 100644
index 000..313da35
--- /dev/null
+++ b/drivers/uio/uio_pci_generic.c
@@ -0,0 +1,207 @@
+/* uio_pci_generic - generic UIO driver for PCI 2.3 devices
+ *
+ * Copyright (C) 2009 Red Hat, Inc.
+ * Author: Michael S. Tsirkin m...@redhat.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.
+ *
+ * Since the driver does not declare any device ids, you must allocate
+ * id and bind the device to the driver yourself.  For example:
+ *
+ * # echo 8086 10f5  /sys/bus/pci/drivers/uio_pci_generic/new_id
+ * # echo -n :00:19.0  /sys/bus/pci/drivers/e1000e/unbind
+ * # echo -n :00:19.0  /sys/bus/pci/drivers/uio_pci_generic/bind
+ * # ls -l /sys/bus/pci/devices/:00:19.0/driver
+ * .../:00:19.0/driver - ../../../bus/pci/drivers/uio_pci_generic
+ *
+ * Driver won't bind to devices which do not support the Interrupt Disable Bit
+ * in the command register. All devices compliant to PCI 2.3 (circa 2002) and
+ * all compliant PCI Express devices should support this bit.
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/uio_driver.h
+#include linux/spinlock.h
+
+#define DRIVER_VERSION 0.01.0
+#define DRIVER_AUTHOR  Michael S. Tsirkin m...@redhat.com
+#define DRIVER_DESCGeneric UIO driver for PCI 2.3 devices
+
+struct uio_pci_generic_dev {
+   struct uio_info info;
+   struct pci_dev *pdev;
+   spinlock_t lock; /* guards command register accesses */
+};
+
+static inline struct uio_pci_generic_dev *

Re: [PATCH 08/10] Move IO APIC to its own lock.

[Gleb Natapov]

On Wed, Jul 15, 2009 at 02:57:59PM -0300, Marcelo Tosatti wrote:
 On Tue, Jul 14, 2009 at 05:30:43PM +0300, Gleb Natapov wrote:
  
  Signed-off-by: Gleb Natapov g...@redhat.com
  ---
   arch/ia64/kvm/kvm-ia64.c |   27 ++--
   arch/x86/kvm/lapic.c |5 +---
   arch/x86/kvm/x86.c   |   30 ++-
   virt/kvm/ioapic.c|   50 
  -
   virt/kvm/ioapic.h|1 +
   5 files changed, 73 insertions(+), 40 deletions(-)
  
  diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
  index 0ad09f0..dd7ef2d 100644
  --- a/arch/ia64/kvm/kvm-ia64.c
  +++ b/arch/ia64/kvm/kvm-ia64.c
  @@ -850,9 +850,16 @@ static int kvm_vm_ioctl_get_irqchip(struct kvm *kvm,
   
  r = 0;
  switch (chip-chip_id) {
  -   case KVM_IRQCHIP_IOAPIC:
  -   memcpy(chip-chip.ioapic, ioapic_irqchip(kvm),
  -   sizeof(struct kvm_ioapic_state));
  +   case KVM_IRQCHIP_IOAPIC: {
  +   struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
  +   if (ioapic) {
  +   spin_lock(ioapic-lock);
  +   memcpy(chip-chip.ioapic, ioapic,
  +  sizeof(struct kvm_ioapic_state));
  +   spin_unlock(ioapic-lock);
  +   } else
  +   r = -EINVAL;
  +   }
  break;
  default:
  r = -EINVAL;
  @@ -867,10 +874,16 @@ static int kvm_vm_ioctl_set_irqchip(struct kvm *kvm, 
  struct kvm_irqchip *chip)
   
  r = 0;
  switch (chip-chip_id) {
  -   case KVM_IRQCHIP_IOAPIC:
  -   memcpy(ioapic_irqchip(kvm),
  -   chip-chip.ioapic,
  -   sizeof(struct kvm_ioapic_state));
  +   case KVM_IRQCHIP_IOAPIC: {
  +   struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
  +   if (ioapic) {
  +   spin_lock(ioapic-lock);
  +   memcpy(ioapic, chip-chip.ioapic,
  +  sizeof(struct kvm_ioapic_state));
  +   spin_unlock(ioapic-lock);
  +   } else
  +   r = -EINVAL;
  +   }
  break;
  default:
  r = -EINVAL;
  diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
  index e2e2849..61ffcfc 100644
  --- a/arch/x86/kvm/lapic.c
  +++ b/arch/x86/kvm/lapic.c
  @@ -471,11 +471,8 @@ static void apic_set_eoi(struct kvm_lapic *apic)
  trigger_mode = IOAPIC_LEVEL_TRIG;
  else
  trigger_mode = IOAPIC_EDGE_TRIG;
  -   if (!(apic_get_reg(apic, APIC_SPIV)  APIC_SPIV_DIRECTED_EOI)) {
  -   mutex_lock(apic-vcpu-kvm-irq_lock);
  +   if (!(apic_get_reg(apic, APIC_SPIV)  APIC_SPIV_DIRECTED_EOI))
  kvm_ioapic_update_eoi(apic-vcpu-kvm, vector, trigger_mode);
  -   mutex_unlock(apic-vcpu-kvm-irq_lock);
  -   }
   }
   
   static void apic_send_ipi(struct kvm_lapic *apic)
  diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
  index 48567fa..de99b84 100644
  --- a/arch/x86/kvm/x86.c
  +++ b/arch/x86/kvm/x86.c
  @@ -2010,10 +2010,16 @@ static int kvm_vm_ioctl_get_irqchip(struct kvm 
  *kvm, struct kvm_irqchip *chip)
  pic_irqchip(kvm)-pics[1],
  sizeof(struct kvm_pic_state));
  break;
  -   case KVM_IRQCHIP_IOAPIC:
  -   memcpy(chip-chip.ioapic,
  -   ioapic_irqchip(kvm),
  -   sizeof(struct kvm_ioapic_state));
  +   case KVM_IRQCHIP_IOAPIC: {
  +   struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
  +   if (ioapic) {
  +   spin_lock(ioapic-lock);
  +   memcpy(chip-chip.ioapic, ioapic,
  +  sizeof(struct kvm_ioapic_state));
  +   spin_unlock(ioapic-lock);
  +   } else
  +   r = -EINVAL;
  +   }
  break;
  default:
  r = -EINVAL;
  @@ -2042,12 +2048,16 @@ static int kvm_vm_ioctl_set_irqchip(struct kvm 
  *kvm, struct kvm_irqchip *chip)
  sizeof(struct kvm_pic_state));
  spin_unlock(pic_irqchip(kvm)-lock);
  break;
  -   case KVM_IRQCHIP_IOAPIC:
  -   mutex_lock(kvm-irq_lock);
  -   memcpy(ioapic_irqchip(kvm),
  -   chip-chip.ioapic,
  -   sizeof(struct kvm_ioapic_state));
  -   mutex_unlock(kvm-irq_lock);
  +   case KVM_IRQCHIP_IOAPIC: {
  +   struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
  +   if (ioapic) {
  +   spin_lock(ioapic-lock);
  +   memcpy(ioapic, chip-chip.ioapic,
  +  sizeof(struct kvm_ioapic_state));
  +   spin_unlock(ioapic-lock);
  +   } else
  +   r = -EINVAL;
  +   }
  break;
  default:
  r = -EINVAL;
  diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
  index fa05f67..300ee3b 100644
  --- 

Re: [PATCH 10/10] Change irq routing table to use gsi indexed array.

[Gleb Natapov]

On Wed, Jul 15, 2009 at 10:17:22PM +0300, Michael S. Tsirkin wrote:
 On Tue, Jul 14, 2009 at 05:30:45PM +0300, Gleb Natapov wrote:
  @@ -147,14 +149,13 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, 
  int irq, int level)
   * writes to the unused one.
   */
  rcu_read_lock();
  -   for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
  -   if (e-gsi == irq) {
  -   int r = e-set(e, kvm, sig_level);
  -   if (r  0)
  -   continue;
  +   irq_rt = rcu_dereference(kvm-irq_routing);
  +   hlist_for_each_entry(e, n, irq_rt-map[irq], link) {
 
 Don't you need to range-check irq? E.g. with irqfd, gsi is
 controlled by guest.
 
Yes, I need to add range checking. Good point.

  +   int r = e-set(e, kvm, sig_level);
  +   if (r  0)
  +   continue;
   
  -   ret = r + ((ret  0) ? 0 : ret);
  -   }
  +   ret = r + ((ret  0) ? 0 : ret);
  }
  rcu_read_unlock();
  return ret;
  @@ -162,21 +163,16 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, 
  int irq, int level)
   
   void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
   {
  -   struct kvm_kernel_irq_routing_entry *e;
  struct kvm_irq_ack_notifier *kian;
  struct hlist_node *n;
  -   unsigned gsi = pin;
  +   unsigned gsi;
   
  trace_kvm_ack_irq(irqchip, pin);
   
  rcu_read_lock();
  -   for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
  -   if (e-irqchip.irqchip == irqchip 
  -   e-irqchip.pin == pin) {
  -   gsi = e-gsi;
  -   break;
  -   }
  -   }
  +   gsi = rcu_dereference(kvm-irq_routing)-chip[irqchip][pin];
 
 And possibly here as well. Can guest control pin?
 
  +   if (gsi == -1)
  +   gsi = pin;
   
  hlist_for_each_entry_rcu(kian, n, kvm-irq_ack_notifier_list, link)
  if (kian-gsi == gsi)
  @@ -277,7 +273,8 @@ void kvm_free_irq_routing(struct kvm *kvm)
  kfree(kvm-irq_routing);
   }
   
  -static int setup_routing_entry(struct kvm_kernel_irq_routing_entry *e,
  +static int setup_routing_entry(struct kvm_irq_routing_table *rt,
  +  struct kvm_kernel_irq_routing_entry *e,
 const struct kvm_irq_routing_entry *ue)
   {
  int r = -EINVAL;
  @@ -303,6 +300,7 @@ static int setup_routing_entry(struct 
  kvm_kernel_irq_routing_entry *e,
  }
  e-irqchip.irqchip = ue-u.irqchip.irqchip;
  e-irqchip.pin = ue-u.irqchip.pin + delta;
  +   rt-chip[ue-u.irqchip.irqchip][e-irqchip.pin] = ue-gsi;
  break;
  case KVM_IRQ_ROUTING_MSI:
  e-set = kvm_set_msi;
  @@ -313,6 +311,8 @@ static int setup_routing_entry(struct 
  kvm_kernel_irq_routing_entry *e,
  default:
  goto out;
  }
  +
  +   hlist_add_head(e-link, rt-map[e-gsi]);
  r = 0;
   out:
  return r;
  @@ -324,23 +324,37 @@ int kvm_set_irq_routing(struct kvm *kvm,
  unsigned nr,
  unsigned flags)
   {
  -   struct kvm_kernel_irq_routing_entry *new, *old;
  -   unsigned i;
  +   struct kvm_irq_routing_table *new, *old;
  +   u32 i, j, max_gsi = 0;
  int r;
   
  -   /* last elemet is left zeored and indicates the end of the array */
  -   new = kzalloc(sizeof(*new) * (nr + 1), GFP_KERNEL);
  +   for (i = 0; i  nr; ++i) {
  +   if (ue[i].gsi = KVM_MAX_IRQ_ROUTES)
  +   return -EINVAL;
  +   max_gsi = max(max_gsi, ue[i].gsi);
  +   }
  +
  +   max_gsi += 1;
  +
  +   new = kzalloc(sizeof(*new) + (max_gsi * sizeof(struct hlist_head)) +
  + (nr * sizeof(struct kvm_kernel_irq_routing_entry)),
  + GFP_KERNEL);
   
  if (!new)
  return -ENOMEM;
   
  +   new-rt_entries = (void *)new-map[max_gsi];
  +
  +   new-max_gsi = max_gsi;
  +   for (i = 0; i  3; i++)
  +   for (j = 0; j  KVM_IOAPIC_NUM_PINS; j++)
  +   new-chip[i][j] = -1;
  +
  for (i = 0; i  nr; ++i) {
  r = -EINVAL;
  -   if (ue-gsi = KVM_MAX_IRQ_ROUTES)
  -   goto out;
  if (ue-flags)
  goto out;
  -   r = setup_routing_entry(new + i, ue);
  +   r = setup_routing_entry(new, new-rt_entries[i], ue);
  if (r)
  goto out;
  ++ue;
  -- 
  1.6.2.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

--
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 10/10] Change irq routing table to use gsi indexed array.

[Gleb Natapov]

On Wed, Jul 15, 2009 at 03:18:00PM -0300, Marcelo Tosatti wrote:
 On Tue, Jul 14, 2009 at 05:30:45PM +0300, Gleb Natapov wrote:
  Use gsi indexed array instead of scanning all entries on each interrupt
  injection. Also maintain back mapping from irqchip/pin to gsi to speedup
  interrupt acknowledgment notifications.
  
  Signed-off-by: Gleb Natapov g...@redhat.com
  ---
   include/linux/kvm_host.h |   11 ++-
   virt/kvm/irq_comm.c  |   62 
  -
   2 files changed, 47 insertions(+), 26 deletions(-)
  
  diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
  index aa64d0d..ae6cbf1 100644
  --- a/include/linux/kvm_host.h
  +++ b/include/linux/kvm_host.h
  @@ -128,7 +128,14 @@ struct kvm_kernel_irq_routing_entry {
  } irqchip;
  struct msi_msg msi;
  };
  -   struct list_head link;
  +   struct hlist_node link;
  +};
  +
  +struct kvm_irq_routing_table {
  +   int chip[3][KVM_IOAPIC_NUM_PINS];
  +   struct kvm_kernel_irq_routing_entry *rt_entries;
  +   u32 max_gsi;
  +   struct hlist_head map[0];
   };
   
   struct kvm {
  @@ -165,7 +172,7 @@ struct kvm {
   #endif
   
   #ifdef CONFIG_HAVE_KVM_IRQCHIP
  -   struct kvm_kernel_irq_routing_entry *irq_routing;
  +   struct kvm_irq_routing_table *irq_routing;
  spinlock_t irq_routing_lock;
  struct hlist_head mask_notifier_list;
  struct hlist_head irq_ack_notifier_list;
  diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
  index c54a28b..da643d4 100644
  --- a/virt/kvm/irq_comm.c
  +++ b/virt/kvm/irq_comm.c
  @@ -125,6 +125,8 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, int 
  irq, int level)
  struct kvm_kernel_irq_routing_entry *e;
  unsigned long *irq_state, sig_level;
  int ret = -1;
  +   struct kvm_irq_routing_table *irq_rt;
  +   struct hlist_node *n;
   
  trace_kvm_set_irq(irq, level, irq_source_id);
   
  @@ -147,14 +149,13 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, 
  int irq, int level)
   * writes to the unused one.
   */
  rcu_read_lock();
  -   for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
  -   if (e-gsi == irq) {
  -   int r = e-set(e, kvm, sig_level);
  -   if (r  0)
  -   continue;
  +   irq_rt = rcu_dereference(kvm-irq_routing);
  +   hlist_for_each_entry(e, n, irq_rt-map[irq], link) {
  +   int r = e-set(e, kvm, sig_level);
  +   if (r  0)
  +   continue;
   
  -   ret = r + ((ret  0) ? 0 : ret);
  -   }
  +   ret = r + ((ret  0) ? 0 : ret);
  }
  rcu_read_unlock();
  return ret;
  @@ -162,21 +163,16 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, 
  int irq, int level)
   
   void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
   {
  -   struct kvm_kernel_irq_routing_entry *e;
  struct kvm_irq_ack_notifier *kian;
  struct hlist_node *n;
  -   unsigned gsi = pin;
  +   unsigned gsi;
   
  trace_kvm_ack_irq(irqchip, pin);
   
  rcu_read_lock();
  -   for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
  -   if (e-irqchip.irqchip == irqchip 
  -   e-irqchip.pin == pin) {
  -   gsi = e-gsi;
  -   break;
  -   }
  -   }
  +   gsi = rcu_dereference(kvm-irq_routing)-chip[irqchip][pin];
  +   if (gsi == -1)
  +   gsi = pin;
   
  hlist_for_each_entry_rcu(kian, n, kvm-irq_ack_notifier_list, link)
  if (kian-gsi == gsi)
  @@ -277,7 +273,8 @@ void kvm_free_irq_routing(struct kvm *kvm)
  kfree(kvm-irq_routing);
   }
   
  -static int setup_routing_entry(struct kvm_kernel_irq_routing_entry *e,
  +static int setup_routing_entry(struct kvm_irq_routing_table *rt,
  +  struct kvm_kernel_irq_routing_entry *e,
 const struct kvm_irq_routing_entry *ue)
   {
  int r = -EINVAL;
  @@ -303,6 +300,7 @@ static int setup_routing_entry(struct 
  kvm_kernel_irq_routing_entry *e,
  }
  e-irqchip.irqchip = ue-u.irqchip.irqchip;
  e-irqchip.pin = ue-u.irqchip.pin + delta;
  +   rt-chip[ue-u.irqchip.irqchip][e-irqchip.pin] = ue-gsi;
  break;
  case KVM_IRQ_ROUTING_MSI:
  e-set = kvm_set_msi;
  @@ -313,6 +311,8 @@ static int setup_routing_entry(struct 
  kvm_kernel_irq_routing_entry *e,
  default:
  goto out;
  }
  +
  +   hlist_add_head(e-link, rt-map[e-gsi]);
  r = 0;
   out:
  return r;
  @@ -324,23 +324,37 @@ int kvm_set_irq_routing(struct kvm *kvm,
  unsigned nr,
  unsigned flags)
   {
  -   struct kvm_kernel_irq_routing_entry *new, *old;
  -   unsigned i;
  +   struct kvm_irq_routing_table *new, *old;
  +   u32 i, j, max_gsi = 0;
  int r;
   
  -   /* last elemet is left zeored and indicates the end of the array */
  -   new 

Re: [Qemu-devel] [PATCH] rev3: support colon in filenames

[Jan Kiszka]

Jamie Lokier wrote:
 Kevin Wolf wrote:
 Can we at least allow \, instead of ,, in parameter parsing, so that the
 backslash has the practical benefit of being a single universal escape
 character?
 
 Is there a good reason why we cannot simply use \char to escape
 _any_ character, in every context where a user-supplied
 string/name/path/file is used?
 
 I'm thinking of consistency here.  Instead of special cases for
 filenames, why not a standard scheme for all the places in command
 lines _and_ the monitor where a name/path/file is needed?

Yeah, consistency. Very good point.

 
 There are many examples where it would be useful if unusual characters
 didn't break things, they simply worked.
 
 Examples: -vnc unix: path, -net port: device path, -net script path,
 -net sock= path, -net group= groupname, tap and bt device names.
 
 \char is an obvious scheme to standardise on given QEMU's unix shell
 heritage.  It would work equally well for command line options (which
 are often comma-separated) and for monitor commands (which are often
 space-separated).
 
 It would have the nice property of being easy for management
 programs/scripts to quote, without them having a special list of
 characters to quote, without needing to update them if QEMU needs to
 quote more characters in future for some reason.
 
 Now, I see one significant hurdle with that: it's quite inconvenient
 for Windows users, typing paths like c:\path\to\dir\file, if those
 backslashes are stipped.

We could exclude Windows from this (I think to remember that filenames
are more restricted there anyway) or define a different, Windows-only
escape character.

 
 So I propose this as a universal quoting scheme:
 
 \char where char is not ASCII alphanumeric.
 
 Shell quoting is easy:
 
qfile=`printf %s $file | sed 's/[^0-9a-zA-Z]//g'`
 
qemu -drive file=$qfile,if=scsi,media=disk
 
 Same quoting applied when sending the monitor a command to change a
 CD-ROM file or add a USB disk, for example.
 

To me this direction looks more promising than any other proposal so far.

Jan



signature.asc
Description: OpenPGP digital signature

qcow2 relative paths (was: [PATCH] rev5: support colon in filenames)

[Jamie Lokier]

Ram Pai wrote:
 I have successfully verified qcow2 files. But then I may not be trying
 out the exact thing that you are talking about. Can you give me a test 
 case that I can verify.

Commands tried with qemu-0.10.0-1ubuntu1:

$ mkdir unlikely_subdir
$ cd unlikely_subdir
$ qemu-img create -f qcow2 backing.img 10
Formatting 'backing.img', fmt=qcow2, size=10 kB
$ qemu-img create -f qcow2 -b ../unlikely_subdir/backing.img main.img 10
Formatting 'main.img', fmt=qcow2, backing_file=../unlikely_subdir/backing.img, 
size=10 kB
$ cd ..
$ qemu-img info unlikely_subdir/main.img 
image: unlikely_subdir/main.img
file format: qcow2
virtual size: 10K (10240 bytes)
disk size: 16K
cluster_size: 4096
highest_alloc: 16384
backing file: ../unlikely_subdir/backing.img (actual path: 
unlikely_subdir/../unlikely_subdir/backing.img)

See especially the actual path line.

$ mv unlikely_subdir other_subdir
$ ls -l other_subdir
total 32
-rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 backing.img
-rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 main.img
$ qemu-img info other_subdir/main.img 
qemu-img: Could not open 'other_subdir/main.img'

What an unhelpful error message...  There isn't even a way to find out
the backing file path which the tool is looking for.

 And one other thing. Let me know if there a test-suite that I can try
 for regressions.

Sorry, I don't know anything about any QEMU test suites.

-- Jamie
--
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: qcow2 relative paths

[Jan Kiszka]

Jamie Lokier wrote:
 Ram Pai wrote:
 I have successfully verified qcow2 files. But then I may not be trying
 out the exact thing that you are talking about. Can you give me a test 
 case that I can verify.
 
 Commands tried with qemu-0.10.0-1ubuntu1:
 
 $ mkdir unlikely_subdir
 $ cd unlikely_subdir
 $ qemu-img create -f qcow2 backing.img 10
 Formatting 'backing.img', fmt=qcow2, size=10 kB
 $ qemu-img create -f qcow2 -b ../unlikely_subdir/backing.img main.img 10
 Formatting 'main.img', fmt=qcow2, 
 backing_file=../unlikely_subdir/backing.img, size=10 kB
 $ cd ..
 $ qemu-img info unlikely_subdir/main.img 
 image: unlikely_subdir/main.img
 file format: qcow2
 virtual size: 10K (10240 bytes)
 disk size: 16K
 cluster_size: 4096
 highest_alloc: 16384
 backing file: ../unlikely_subdir/backing.img (actual path: 
 unlikely_subdir/../unlikely_subdir/backing.img)
 
 See especially the actual path line.
 
 $ mv unlikely_subdir other_subdir
 $ ls -l other_subdir
 total 32
 -rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 backing.img
 -rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 main.img
 $ qemu-img info other_subdir/main.img 
 qemu-img: Could not open 'other_subdir/main.img'
 
 What an unhelpful error message...  There isn't even a way to find out
 the backing file path which the tool is looking for.

strace :p

But I feel your pain. This screams for better error reporting.

 
 And one other thing. Let me know if there a test-suite that I can try
 for regressions.
 
 Sorry, I don't know anything about any QEMU test suites.

There is kvm autotest, but that's testing at a coarser level. Well,
Anthony promised to push some unit test framework for QEMU...

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] rev3: support colon in filenames

[Jamie Lokier]

Jan Kiszka wrote:
  Now, I see one significant hurdle with that: it's quite inconvenient
  for Windows users, typing paths like c:\path\to\dir\file, if those
  backslashes are stipped.
 
 We could exclude Windows from this (I think to remember that filenames
 are more restricted there anyway) or define a different, Windows-only
 escape character.

I think both of those are bad ideas, because the same management
scripts can run on Windows, and for consistency it's not just file
names.  Even Windows has block devices and network devices :-)

Fortunately where char is not ASCII alphanumeric solves the
practical cases where the user types an ordinary pathname.

Or the user can type forward slashes just like they do in unix.

  So I propose this as a universal quoting scheme:
  
  \char where char is not ASCII alphanumeric.
  
  Shell quoting is easy:
  
 qfile=`printf %s $file | sed 's/[^0-9a-zA-Z]//g'`
  
 qemu -drive file=$qfile,if=scsi,media=disk

I forgot a very obscure corner case, where the last character of the
filename is a newline character.  To do the right thing (with Bash at
least), it should say '%s\n' instead of %s. Sue me :-)

  Same quoting applied when sending the monitor a command to change a
  CD-ROM file or add a USB disk, for example.
 
 To me this direction looks more promising than any other proposal so far.

I wondered if it was just me...

-- Jamie
--
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 08/10] Move IO APIC to its own lock.

[Marcelo Tosatti]

On Wed, Jul 15, 2009 at 11:48:17PM +0300, Gleb Natapov wrote:
   + spin_unlock(ioapic-lock);
   + kvm_notify_acked_irq(ioapic-kvm, KVM_IRQCHIP_IOAPIC, i);
   + spin_lock(ioapic-lock);
  
  While traversing the IOAPIC pins you drop the lock and acquire it again,
  which is error prone: what if the redirection table is changed in
  between, for example?
  
 Yes, the ack notifiers is a problematic part. The only thing that
 current ack notifiers do is set_irq_level(0) so this is not the problem
 in practice. I'll see if I can eliminate this dropping of the lock here.

Currently, yes. But take into account that an ack notifier might do 
other things than set_irq_level(0).

Say for example an ack notifier that takes the PIC or IOAPIC lock 
(for whatever reason).

  Also, irq_lock was held during ack and mask notifier callbacks, so they
  (the callbacks) did not have to worry about concurrency.
  
 Is it possible to have more then one ack for the same interrupt line at
 the same time?

Why not? But maybe this is a somewhat stupid point, because you can
require the notifiers to handle that.

  You questioned the purpose of irq_lock earlier, and thats what it is:
  synchronization between pic and ioapic blur at the irq notifiers.
  
 Pic has its own locking and it fails miserably in regards ack notifiers.
 I bet nobody tried device assignment with pic. It will not work.

It fails to take irq_lock on automatic EOI because on guest entry 
interrupts are disabled (see d5ecfdd25c412df9c0ecf3ab8e066461fd4f69df).

 irq_lock is indeed used to synchronization ioapic access, but the way
 it is done requires calling kvm_set_irq() with lock held and this adds
 unnecessary lock on a msi irq injection path.
 
  Using RCU to synchronize ack/mask notifier list walk versus list
  addition is good, but i'm not entirely sure that smaller locks like you
  are proposing is a benefit long term (things become much more tricky).
 Without removing irq_lock RCU is useless since the list walking is always
 done with irq_lock held. I see smaller locks as simplification BTW. The
 thing is tricky now, or so I felt while trying to understand what
 irq_lock actually protects. With smaller locks with names that clearly
 indicates which data structure it protects I feel the code is much
 easy to understand.

What is worrying is if you need to take both PIC and IOAPIC locks for 
some operation (then have to worry about lock ordering etc).

  Maybe it is the only way forward (and so you push this complexity to the
  ack/mask notifiers), but i think it can be avoided until its proven that
  there is contention on irq_lock (which is reduced by faster search).
 This is not about contention. This is about existence of the lock in the
 first place. With the patch set there is no lock at msi irq injection
 path at all and this is better than having lock no matter if the lock is
 congested or not. There is still a lock on ioapic path (which MSI does
 not use) and removing of this lock should be done only after we see
 that it is congested, because removing it involves adding a number of
 atomic accesses, so it is not clear win without lock contention.
 (removing it will also solve ack notification problem hmmm)

--
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: [PATCHv4] uio: add generic driver for PCI 2.3 devices

[Hans J. Koch]

On Wed, Jul 15, 2009 at 11:13:40PM +0300, Michael S. Tsirkin wrote:
 This adds a generic uio driver that can bind to any PCI device.  First
 user will be virtualization where a qemu userspace process needs to give
 guest OS access to the device.
 
 Interrupts are handled using the Interrupt Disable bit in the PCI command
 register and Interrupt Status bit in the PCI status register.  All devices
 compliant to PCI 2.3 (circa 2002) and all compliant PCI Express devices should
 support these bits.  Driver detects this support, and won't bind to devices
 which do not support the Interrupt Disable Bit in the command register.
 
 It's expected that more features of interest to virtualization will be
 added to this driver in the future. Possibilities are: mmap for device
 resources, MSI/MSI-X, eventfd (to interface with kvm), iommu.

Well, I'm not enough of a PCI expert to tell whether your 2.3-test works or
not (can it have side effects, e.g. trigger an interrupt when you toggle that
bit?). I've added Jesse Barnes to Cc: since you modify a PCI core header file.
If there are no objections from the PCI people, I guess we can take this.

Thanks,
Hans

 
 Acked-by: Chris Wright chr...@redhat.com
 Signed-off-by: Michael S. Tsirkin m...@redhat.com

Signed-off-by: Hans J. Koch h...@linutronix.de

 ---
 
 Hans, Greg, please review and consider for upstream.
 
 This is intended to solve the problem in virtualization that shared
 interrupts do not work with assigned devices. Earlier versions of this
 patch have circulated on k...@vger.
 
 Changes since v1:
 - some naming changes
 - do a single read to get both command and status register
 Changes since v2:
 - remove irqcontrol: user can enable interrupts by
   writing command register directly
 - don't claim resources as we don't support mmap yet,
   but note the intent to do so in the commit log
 Changes since v3:
 - minor driver version fix
 
  MAINTAINERS   |8 ++
  drivers/uio/Kconfig   |   10 ++
  drivers/uio/Makefile  |1 +
  drivers/uio/uio_pci_generic.c |  207 
 +
  include/linux/pci_regs.h  |1 +
  5 files changed, 227 insertions(+), 0 deletions(-)
  create mode 100644 drivers/uio/uio_pci_generic.c
 
 diff --git a/MAINTAINERS b/MAINTAINERS
 index 18c3f0c..39c7207 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -2538,6 +2538,14 @@ T: git 
 git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
  S:   Maintained
  F:   include/asm-generic
  
 +GENERIC UIO DRIVER FOR PCI DEVICES
 +P:   Michael S. Tsirkin
 +M:   m...@redhat.com
 +L:   kvm@vger.kernel.org
 +L:   linux-ker...@vger.kernel.org
 +S:   Supported
 +F:   drivers/uio/uio_pci_generic.c
 +
  GFS2 FILE SYSTEM
  P:   Steven Whitehouse
  M:   swhit...@redhat.com
 diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
 index 7f86534..0f14c8e 100644
 --- a/drivers/uio/Kconfig
 +++ b/drivers/uio/Kconfig
 @@ -89,4 +89,14 @@ config UIO_SERCOS3
  
 If you compile this as a module, it will be called uio_sercos3.
  
 +config UIO_PCI_GENERIC
 + tristate Generic driver for PCI 2.3 and PCI Express cards
 + depends on PCI
 + default n
 + help
 +   Generic driver that you can bind, dynamically, to any
 +   PCI 2.3 compliant and PCI Express card. It is useful,
 +   primarily, for virtualization scenarios.
 +   If you compile this as a module, it will be called uio_pci_generic.
 +
  endif
 diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
 index 5c2586d..73b2e75 100644
 --- a/drivers/uio/Makefile
 +++ b/drivers/uio/Makefile
 @@ -5,3 +5,4 @@ obj-$(CONFIG_UIO_PDRV_GENIRQ) += uio_pdrv_genirq.o
  obj-$(CONFIG_UIO_SMX)+= uio_smx.o
  obj-$(CONFIG_UIO_AEC)+= uio_aec.o
  obj-$(CONFIG_UIO_SERCOS3)+= uio_sercos3.o
 +obj-$(CONFIG_UIO_PCI_GENERIC)+= uio_pci_generic.o
 diff --git a/drivers/uio/uio_pci_generic.c b/drivers/uio/uio_pci_generic.c
 new file mode 100644
 index 000..313da35
 --- /dev/null
 +++ b/drivers/uio/uio_pci_generic.c
 @@ -0,0 +1,207 @@
 +/* uio_pci_generic - generic UIO driver for PCI 2.3 devices
 + *
 + * Copyright (C) 2009 Red Hat, Inc.
 + * Author: Michael S. Tsirkin m...@redhat.com
 + *
 + * This work is licensed under the terms of the GNU GPL, version 2.
 + *
 + * Since the driver does not declare any device ids, you must allocate
 + * id and bind the device to the driver yourself.  For example:
 + *
 + * # echo 8086 10f5  /sys/bus/pci/drivers/uio_pci_generic/new_id
 + * # echo -n :00:19.0  /sys/bus/pci/drivers/e1000e/unbind
 + * # echo -n :00:19.0  /sys/bus/pci/drivers/uio_pci_generic/bind
 + * # ls -l /sys/bus/pci/devices/:00:19.0/driver
 + * .../:00:19.0/driver - ../../../bus/pci/drivers/uio_pci_generic
 + *
 + * Driver won't bind to devices which do not support the Interrupt Disable 
 Bit
 + * in the command register. All devices compliant to PCI 2.3 (circa 2002) and
 + * all compliant PCI Express devices should support 

Re: [Qemu-devel] [PATCH] rev3: support colon in filenames

[Jan Kiszka]

Jamie Lokier wrote:
 Jan Kiszka wrote:
 Now, I see one significant hurdle with that: it's quite inconvenient
 for Windows users, typing paths like c:\path\to\dir\file, if those
 backslashes are stipped.
 We could exclude Windows from this (I think to remember that filenames
 are more restricted there anyway) or define a different, Windows-only
 escape character.
 
 I think both of those are bad ideas, because the same management
 scripts can run on Windows, and for consistency it's not just file
 names.  Even Windows has block devices and network devices :-)

I'm not sure if there is actually so much portability/reusability
between Windows and the rest of the universe, but I'm surely not an
expert in this.

 
 Fortunately where char is not ASCII alphanumeric solves the
 practical cases where the user types an ordinary pathname.
 
 Or the user can type forward slashes just like they do in unix.

We would still have to deal with the fact that so far '\' had no special
meaning on Windows - except that is was the well-known path separator.
So redefining its meaning would break a bit...

Jan




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 10/10] Change irq routing table to use gsi indexed array.

[Marcelo Tosatti]

On Wed, Jul 15, 2009 at 11:52:24PM +0300, Gleb Natapov wrote:
 On Wed, Jul 15, 2009 at 03:18:00PM -0300, Marcelo Tosatti wrote:
  On Tue, Jul 14, 2009 at 05:30:45PM +0300, Gleb Natapov wrote:
   Use gsi indexed array instead of scanning all entries on each interrupt
   injection. Also maintain back mapping from irqchip/pin to gsi to speedup
   interrupt acknowledgment notifications.
   
   Signed-off-by: Gleb Natapov g...@redhat.com
   ---
include/linux/kvm_host.h |   11 ++-
virt/kvm/irq_comm.c  |   62 
   -
2 files changed, 47 insertions(+), 26 deletions(-)
   
   diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
   index aa64d0d..ae6cbf1 100644
   --- a/include/linux/kvm_host.h
   +++ b/include/linux/kvm_host.h
   @@ -128,7 +128,14 @@ struct kvm_kernel_irq_routing_entry {
 } irqchip;
 struct msi_msg msi;
 };
   - struct list_head link;
   + struct hlist_node link;
   +};
   +
   +struct kvm_irq_routing_table {
   + int chip[3][KVM_IOAPIC_NUM_PINS];
   + struct kvm_kernel_irq_routing_entry *rt_entries;
   + u32 max_gsi;
   + struct hlist_head map[0];
};

struct kvm {
   @@ -165,7 +172,7 @@ struct kvm {
#endif

#ifdef CONFIG_HAVE_KVM_IRQCHIP
   - struct kvm_kernel_irq_routing_entry *irq_routing;
   + struct kvm_irq_routing_table *irq_routing;
 spinlock_t irq_routing_lock;
 struct hlist_head mask_notifier_list;
 struct hlist_head irq_ack_notifier_list;
   diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
   index c54a28b..da643d4 100644
   --- a/virt/kvm/irq_comm.c
   +++ b/virt/kvm/irq_comm.c
   @@ -125,6 +125,8 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, 
   int irq, int level)
 struct kvm_kernel_irq_routing_entry *e;
 unsigned long *irq_state, sig_level;
 int ret = -1;
   + struct kvm_irq_routing_table *irq_rt;
   + struct hlist_node *n;

 trace_kvm_set_irq(irq, level, irq_source_id);

   @@ -147,14 +149,13 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, 
   int irq, int level)
  * writes to the unused one.
  */
 rcu_read_lock();
   - for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
   - if (e-gsi == irq) {
   - int r = e-set(e, kvm, sig_level);
   - if (r  0)
   - continue;
   + irq_rt = rcu_dereference(kvm-irq_routing);
   + hlist_for_each_entry(e, n, irq_rt-map[irq], link) {
   + int r = e-set(e, kvm, sig_level);
   + if (r  0)
   + continue;

   - ret = r + ((ret  0) ? 0 : ret);
   - }
   + ret = r + ((ret  0) ? 0 : ret);
 }
 rcu_read_unlock();
 return ret;
   @@ -162,21 +163,16 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, 
   int irq, int level)

void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned 
   pin)
{
   - struct kvm_kernel_irq_routing_entry *e;
 struct kvm_irq_ack_notifier *kian;
 struct hlist_node *n;
   - unsigned gsi = pin;
   + unsigned gsi;

 trace_kvm_ack_irq(irqchip, pin);

 rcu_read_lock();
   - for (e = rcu_dereference(kvm-irq_routing); e  e-set; e++) {
   - if (e-irqchip.irqchip == irqchip 
   - e-irqchip.pin == pin) {
   - gsi = e-gsi;
   - break;
   - }
   - }
   + gsi = rcu_dereference(kvm-irq_routing)-chip[irqchip][pin];
   + if (gsi == -1)
   + gsi = pin;

 hlist_for_each_entry_rcu(kian, n, kvm-irq_ack_notifier_list, link)
 if (kian-gsi == gsi)
   @@ -277,7 +273,8 @@ void kvm_free_irq_routing(struct kvm *kvm)
 kfree(kvm-irq_routing);
}

   -static int setup_routing_entry(struct kvm_kernel_irq_routing_entry *e,
   +static int setup_routing_entry(struct kvm_irq_routing_table *rt,
   +struct kvm_kernel_irq_routing_entry *e,
const struct kvm_irq_routing_entry *ue)
{
 int r = -EINVAL;
   @@ -303,6 +300,7 @@ static int setup_routing_entry(struct 
   kvm_kernel_irq_routing_entry *e,
 }
 e-irqchip.irqchip = ue-u.irqchip.irqchip;
 e-irqchip.pin = ue-u.irqchip.pin + delta;
   + rt-chip[ue-u.irqchip.irqchip][e-irqchip.pin] = ue-gsi;
 break;
 case KVM_IRQ_ROUTING_MSI:
 e-set = kvm_set_msi;
   @@ -313,6 +311,8 @@ static int setup_routing_entry(struct 
   kvm_kernel_irq_routing_entry *e,
 default:
 goto out;
 }
   +
   + hlist_add_head(e-link, rt-map[e-gsi]);
 r = 0;
out:
 return r;
   @@ -324,23 +324,37 @@ int kvm_set_irq_routing(struct kvm *kvm,
 unsigned nr,
 unsigned flags)
{
   - struct kvm_kernel_irq_routing_entry *new, *old;
   - unsigned i;
   + struct kvm_irq_routing_table *new, *old;
   + u32 i, j, max_gsi = 0;
 int r;

   - /* last elemet is left zeored 

Re: [Qemu-devel] [PATCH] rev3: support colon in filenames

[Jamie Lokier]

Jan Kiszka wrote:
 Jamie Lokier wrote:
  Jan Kiszka wrote:
  Now, I see one significant hurdle with that: it's quite inconvenient
  for Windows users, typing paths like c:\path\to\dir\file, if those
  backslashes are stipped.
  We could exclude Windows from this (I think to remember that filenames
  are more restricted there anyway) or define a different, Windows-only
  escape character.
  
  I think both of those are bad ideas, because the same management
  scripts can run on Windows, and for consistency it's not just file
  names.  Even Windows has block devices and network devices :-)
 
 I'm not sure if there is actually so much portability/reusability
 between Windows and the rest of the universe, but I'm surely not an
 expert in this.

In my experience, shell scripts and Perl scripts tend to work either
with no changes, or very small changes.

  Fortunately where char is not ASCII alphanumeric solves the
  practical cases where the user types an ordinary pathname.
  
  Or the user can type forward slashes just like they do in unix.
 
 We would still have to deal with the fact that so far '\' had no special
 meaning on Windows - except that is was the well-known path separator.
 So redefining its meaning would break a bit...

The point is that paths tend to have alphanumeric characters at the
start of each component, so it doesn't matter in most cases that it's
redefined.  People won't notice because c:\path\to\file will continue
to work, whether it's by itself or part of a multi-option option.

Exceptions are \\host\path and \\.\device, where the error will be so
obvious they'll learn quickly.  We could find a more complex scheme
where \\ is unaffected, but complex is not good and will be wrongly
implemented by other programs.

Whereas \char is very common, well known and easy to get right, even
when people guess how it's done, like they do when working out how to
quote paths for rsync and ssh.

Oh, I'm suddenly thinking that . should be included in alphanumeric :-)

-- Jamie
--
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: [PATCHv4] uio: add generic driver for PCI 2.3 devices

[Greg KH]

On Wed, Jul 15, 2009 at 11:13:40PM +0300, Michael S. Tsirkin wrote:
 This adds a generic uio driver that can bind to any PCI device.  First
 user will be virtualization where a qemu userspace process needs to give
 guest OS access to the device.
 
 Interrupts are handled using the Interrupt Disable bit in the PCI command
 register and Interrupt Status bit in the PCI status register.  All devices
 compliant to PCI 2.3 (circa 2002) and all compliant PCI Express devices should
 support these bits.  Driver detects this support, and won't bind to devices
 which do not support the Interrupt Disable Bit in the command register.
 
 It's expected that more features of interest to virtualization will be
 added to this driver in the future. Possibilities are: mmap for device
 resources, MSI/MSI-X, eventfd (to interface with kvm), iommu.
 
 Acked-by: Chris Wright chr...@redhat.com
 Signed-off-by: Michael S. Tsirkin m...@redhat.com
 ---
 
 Hans, Greg, please review and consider for upstream.
 
 This is intended to solve the problem in virtualization that shared
 interrupts do not work with assigned devices. Earlier versions of this
 patch have circulated on k...@vger.

How does this play with the pci-stub driver that I thought was written
to solve this very problem?  Will it conflict?

In fact, it looks like you copied the comments for this driver directly
from the pci-stub driver :)

How about moving that documentation into a place that people will notice
it, like the rest of the UIO documentation?

And right now you are just sending the irq to userspace, what is
userspace supposed to do with it?  Do you have a userspace program that
uses this interface today to verify that everything works?  If so, care
to provide a pointer to it?

thanks,

greg k-h
--
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] rev3: support colon in filenames

[Anthony Liguori]

Jan Kiszka wrote:

We would still have to deal with the fact that so far '\' had no special
meaning on Windows - except that is was the well-known path separator.
So redefining its meaning would break a bit...
  


That's the problem.  You will break existing Windows users.

I know this goes against the current momentum in qemu, but overloading 
one option with a bunch of parameters seems absolutely silly to me.


IMHO, -drive file=foo.img,if=virtio,cache=off should have always been at 
least three parameters.


--
Regards,

Anthony Liguori

--
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] rev3: support colon in filenames

[Jamie Lokier]

Anthony Liguori wrote:
 Jan Kiszka wrote:
 We would still have to deal with the fact that so far '\' had no special
 meaning on Windows - except that is was the well-known path separator.
 So redefining its meaning would break a bit...
   
 
 That's the problem.  You will break existing Windows users.
 
 I know this goes against the current momentum in qemu, but overloading 
 one option with a bunch of parameters seems absolutely silly to me.
 
 IMHO, -drive file=foo.img,if=virtio,cache=off should have always been at 
 least three parameters.

That's fine for command lines.  I don't necessarily disagree with you.

But how do you propose to handle paths in monitor commands, when the
path contains a space/quote/whatever as it often does on Windows (My
Documents, Program Files)?

-- Jamie
--
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] rev3: support colon in filenames

[Anthony Liguori]

Jamie Lokier wrote:

Anthony Liguori wrote:
  

Jan Kiszka wrote:


We would still have to deal with the fact that so far '\' had no special
meaning on Windows - except that is was the well-known path separator.
So redefining its meaning would break a bit...
 
  

That's the problem.  You will break existing Windows users.

I know this goes against the current momentum in qemu, but overloading 
one option with a bunch of parameters seems absolutely silly to me.


IMHO, -drive file=foo.img,if=virtio,cache=off should have always been at 
least three parameters.



That's fine for command lines.  I don't necessarily disagree with you.

But how do you propose to handle paths in monitor commands, when the
path contains a space/quote/whatever as it often does on Windows (My
Documents, Program Files)?
  


Same basic rules apply.  The monitor should use shell-style quoting.

--
Regards,

Anthony Liguori

--
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] rev3: support colon in filenames

[Jamie Lokier]

Anthony Liguori wrote:
 Jamie Lokier wrote:
 Anthony Liguori wrote:
   
 Jan Kiszka wrote:
 
 We would still have to deal with the fact that so far '\' had no special
 meaning on Windows - except that is was the well-known path separator.
 So redefining its meaning would break a bit...
  
   
 That's the problem.  You will break existing Windows users.
 
 I know this goes against the current momentum in qemu, but overloading 
 one option with a bunch of parameters seems absolutely silly to me.
 
 IMHO, -drive file=foo.img,if=virtio,cache=off should have always been at 
 least three parameters.
 
 
 That's fine for command lines.  I don't necessarily disagree with you.
 
 But how do you propose to handle paths in monitor commands, when the
 path contains a space/quote/whatever as it often does on Windows (My
 Documents, Program Files)?
   
 
 Same basic rules apply.  The monitor should use shell-style quoting.

So instead of consistency, you like the idea of using different
quoting rules for the monitor than for command line arguments?

-- Jamie
--
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

Trouble understanding net config options

[Michael Jinks]

On my desktop I have KVM working and one guest running, with the command line:

 # kvm -m 512M -net nic -net tap -hda /dev/mapper/pile-evil64 -boot c
-vnc :2 -smp 2 -nographic

Next I need to set up a virtual network for testing.  The plan calls
for four guest systems, and two virtual networks, one connected to the
outside world through eth0, and the other with no gateway, just
passing traffic back and forth between the VM's.  All the VM's wil
need to have two NICs each, one connected to each of the two virtual
networks.

So, having the OS automatically assign tap interfaces to guest NICs
isn't going to work.  I need to specify which tap goes to which
virtual bridge, and I'd like that to be consistent across VM reboots.

I have the bridges and several tap interfaces configured.  Here's my
'brctl show' output:

bridge name bridge id   STP enabled interfaces
br0 8000.00144fa1f17a   no  eth0
tap0
tap1
tap12
tap14
tap16
tap18
br1 8000.deadbeef3200   no  tap11
tap13
tap15
tap17
tap9

Now I want to bring up a VM with two NICs, one attached to tap12
(bridge 0), the other on tap11 (bridge 1), but I think I've
misunderstood the versious -net options as described in the kvm man
page.  It *seems* to say that the way to map a specific tap to a
specific guest NIC is to say, -net nic followed by -net
tap,name=name of the tap from the host OS's perspective, and repeat
that sequence for each nic to appear within the VM.

So, here's the full command line I tried, based on that reading:

  # kvm -m 512M -net nic -net tap,name=tap11 -net nic -net
tap,name=tap12 -hda /vmstore/wee -vnc :11 -cdrom
/path/to/my/Windows.iso -boot d

But when I try that, the host OS brings up two new tap interfaces
(tap2 and tap3), the guest OS never boots (at least, nothing pops up
on its console through VNC), and networking on my system completely
freezes up until I kill -9 the kvm process (kill -15 is ignored) and
restart br0.

I tried fd= instead of name=, but that looks for a file descriptor
instead of a network interface name, and I didn't even know that Linux
had file descriptors for network interfaces let alone how to map them
to a tap.  Nothing under /dev looks promising.

Clearly, I am confused.
--
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] always report x2apic as supported feature

[Marcelo Tosatti]

On Sun, Jul 12, 2009 at 04:10:55PM +0300, Gleb Natapov wrote:
 We emulate x2apic in software, so host support is not required.
 
 Signed-off-by: Gleb Natapov g...@redhat.com
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 00844eb..c256da7 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -1497,6 +1497,9 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 
 *entry, u32 function,
   case 1:
   entry-edx = kvm_supported_word0_x86_features;
   entry-ecx = kvm_supported_word4_x86_features;
 + /* we support x2apic emulation even if host does not support
 +it since we emulate x2apic in software */
 + entry-ecx |= F(X2APIC);
   break;
   /* function 2 entries are STATEFUL. That is, repeated cpuid commands
* may return different values. This forces us to get_cpu() before
 --
   Gleb.

What if you have an older host that does not support emulate x2apic?

--
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: Trouble understanding net config options

[Michael Jinks]

On Wed, Jul 15, 2009 at 6:05 PM, Stephane
Bakhosnuit...@melchior.nuitari.net wrote:

 You need to add a vlan option to one of them, for example vlan=2
 Otherwise kvm will bridge the interfaces together, and it's going to create
 a packet storm.

I wondered about that -- but what's the relationship of a KVM vlan to
my existing bridge interfaces, and how can I control which one gets
mapped to, say vlan 1 or vlan 2?

Are these redundant?  Should I get rid of the bridges?  Question still
remains about how to control which one connects to a physical NIC...
--
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: Trouble understanding net config options

[Stephane Bakhos]

You need to add a vlan option to one of them, for example vlan=2
Otherwise kvm will bridge the interfaces together, and it's going to create
a packet storm.


I wondered about that -- but what's the relationship of a KVM vlan to
my existing bridge interfaces, and how can I control which one gets
mapped to, say vlan 1 or vlan 2?

Are these redundant?  Should I get rid of the bridges?  Question still
remains about how to control which one connects to a physical NIC...


It's not redundant, it just ensures that each tap is treated as it's own 
lan by kvm and that it isn't bridged together by kvm.


You need to keep the bridges as the kvm process doesn't talk to other kvm 
processes by itself.


--
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: Trouble understanding net config options

[Stephane Bakhos]

bridge name bridge id   STP enabled interfaces
br0 8000.00144fa1f17a   no  eth0
tap0
tap1
tap12
tap14
tap16
tap18
br1 8000.deadbeef3200   no  tap11
tap13
tap15
tap17
tap9

Now I want to bring up a VM with two NICs, one attached to tap12
(bridge 0), the other on tap11 (bridge 1), but I think I've
misunderstood the versious -net options as described in the kvm man
page.  It *seems* to say that the way to map a specific tap to a
specific guest NIC is to say, -net nic followed by -net
tap,name=name of the tap from the host OS's perspective, and repeat
that sequence for each nic to appear within the VM.

So, here's the full command line I tried, based on that reading:

 # kvm -m 512M -net nic -net tap,name=tap11 -net nic -net
tap,name=tap12 -hda /vmstore/wee -vnc :11 -cdrom
/path/to/my/Windows.iso -boot d

But when I try that, the host OS brings up two new tap interfaces
(tap2 and tap3), the guest OS never boots (at least, nothing pops up
on its console through VNC), and networking on my system completely
freezes up until I kill -9 the kvm process (kill -15 is ignored) and
restart br0.

I tried fd= instead of name=, but that looks for a file descriptor
instead of a network interface name, and I didn't even know that Linux
had file descriptors for network interfaces let alone how to map them
to a tap.  Nothing under /dev looks promising.


You need to add a vlan option to one of them, for example vlan=2
Otherwise kvm will bridge the interfaces together, and it's going to 
create a packet storm.

--
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: Trouble understanding net config options

[Andreas Plesner Jacobsen]

On Wed, Jul 15, 2009 at 05:54:14PM -0500, Michael Jinks wrote:
 
 Now I want to bring up a VM with two NICs, one attached to tap12
 (bridge 0), the other on tap11 (bridge 1), but I think I've
 misunderstood the versious -net options as described in the kvm man
 page.  It *seems* to say that the way to map a specific tap to a
 specific guest NIC is to say, -net nic followed by -net
 tap,name=name of the tap from the host OS's perspective, and repeat
 that sequence for each nic to appear within the VM.
 
 So, here's the full command line I tried, based on that reading:
 
   # kvm -m 512M -net nic -net tap,name=tap11 -net nic -net
 tap,name=tap12 -hda /vmstore/wee -vnc :11 -cdrom
 /path/to/my/Windows.iso -boot d

The parameter is ifname, not name.

-- 
Andreas
--
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: Trouble understanding net config options

[Michael Jinks]

On Wed, Jul 15, 2009 at 6:12 PM, Andreas Plesner Jacobsena...@mutt.dk wrote:
 On Wed, Jul 15, 2009 at 07:05:48PM -0400, Stephane Bakhos wrote:

 You need to add a vlan option to one of them, for example vlan=2
 Otherwise kvm will bridge the interfaces together, and it's going to
 create a packet storm.

 Not if the tap-interfaces are connected to different bridges.

In that case... How do I make a guest use a specific tap?  Quoting
from my initial post, my -net options are:

 -net nic -net tap,name=tap11 -net nic -net tap,name=tap12

I think I am getting a packet storm -- which explains why my br0 and
everything on it crashes -- but that's probably because the name=
options are being ignored, and instead KVM is bringing up two new
taps, probably both attached to br0.

So, what's wrong with my name= options?
--
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: Trouble understanding net config options

[Andreas Plesner Jacobsen]

On Wed, Jul 15, 2009 at 07:05:48PM -0400, Stephane Bakhos wrote:

 I tried fd= instead of name=, but that looks for a file descriptor
 instead of a network interface name, and I didn't even know that Linux
 had file descriptors for network interfaces let alone how to map them
 to a tap.  Nothing under /dev looks promising.

 You need to add a vlan option to one of them, for example vlan=2
 Otherwise kvm will bridge the interfaces together, and it's going to  
 create a packet storm.

Not if the tap-interfaces are connected to different bridges.

-- 
Andreas
--
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: Trouble understanding net config options

[Michael Jinks]

   # kvm -m 512M -net nic -net tap,name=tap11 -net nic -net
 tap,name=tap12 -hda /vmstore/wee -vnc :11 -cdrom
 /path/to/my/Windows.iso -boot d

 The parameter is ifname, not name.

In that case, what does the name parameter mean?  Quoting from the
manpage on my system:

   -net tap[,vlan=n][,name=name][,fd=h][,ifname=name][,script=file][,down-
   script=dfile]
   Connect the host TAP network interface name to VLAN n, use the net-
   work script file to configure it and the network script dfile to
   deconfigure it. If name is not provided, the OS automatically pro-
   vides one. fd=h can be used to specify the handle of an already
   opened host TAP interface.

I tried again, substituting ifname for name and leaving everything
else as-is,  That draws an error:

  device tap11 is already a member of a bridge; can't enslave it to bridge br0.
  /etc/kvm/kvm-ifup: could not launch network script
  Could not initialize device 'tap'

I suppose that's a good sign, but it still leaves me wondering how to
control which tap connects to which bridge, if I can't attach a guest
to an existing tap.
--
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: Trouble understanding net config options

[Stephane Bakhos]

 device tap11 is already a member of a bridge; can't enslave it to bridge br0.
 /etc/kvm/kvm-ifup: could not launch network script
 Could not initialize device 'tap'


That's because your kvm-ifup scripts tries to connect the tap to the 
bridge and it's already there. You should either remove it from the bridge 
before hand or remove the brctl addif line from kvm-ifup

--
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

set_link monitor command

[Michael Jinks]

Like I said in my other network puzzlement thread, I have one KVM
guest which is working fine.  Or, it was until I tried to add a second
one, and hosed my virtual bridge.

The guest is still running, but since I restarted the bridge interface
that its NIC was attached to, it's no longer attached.  I thought that
maybe bringing its network interface down and back up again might
re-attach it to the bridge.  (Was I wrong?  Is there some other way to
change the network connections for a running guest?)

I found the set_link monitor command, but I can't figure out what
the link name should be.  I've tried:

(qemu) set_link eth0 up
could not find network device 'eth0'(qemu)
(qemu) set_link tap0 up
could not find network device 'tap0'(qemu)

?
--
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: Trouble understanding net config options

[Andreas Plesner Jacobsen]

On Wed, Jul 15, 2009 at 06:22:56PM -0500, Michael Jinks wrote:
    # kvm -m 512M -net nic -net tap,name=tap11 -net nic -net
  tap,name=tap12 -hda /vmstore/wee -vnc :11 -cdrom
  /path/to/my/Windows.iso -boot d
 
  The parameter is ifname, not name.
 
 In that case, what does the name parameter mean?  Quoting from the
 manpage on my system:
 
-net tap[,vlan=n][,name=name][,fd=h][,ifname=name][,script=file][,down-
script=dfile]

No idea, it's not a supported parameter in the kvm-72 I have on this
machine, maybe it's the name in the qemu console for manipulating the
device.

 I tried again, substituting ifname for name and leaving everything
 else as-is,  That draws an error:
 
   device tap11 is already a member of a bridge; can't enslave it to bridge 
 br0.
   /etc/kvm/kvm-ifup: could not launch network script
   Could not initialize device 'tap'
 
 I suppose that's a good sign, but it still leaves me wondering how to
 control which tap connects to which bridge, if I can't attach a guest
 to an existing tap.

You can. Try adding script=no, so the kvm-ifup script does not get run.

-- 
Andreas
--
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: Trouble understanding net config options

[Michael Jinks]

On Wed, Jul 15, 2009 at 6:24 PM, Chris Webbch...@arachsys.com wrote:
 You want

  -net nic,vlan=0 -net tap,vlan=0,ifname=tap11 -net nic,vlan=1 -net 
 tap,vlan=1,ifname=tap12

Progress!  This works, I can bring up the guest and watch it boot, but
both of its NICs came up bound to the first bridge on the system.

I can work around that using 'brctl delif' and 'brctl addif' on the
host system, but how would I automate it so that, say, tap11 always
goes to br1, and tap12 always goes to br0?  I guess by taking out the
brctl in the kvm ifup script, and pre-setting all my bridge/tap
connections?

I think that brctl command in the kvm-ifup script is a (distro) bug.
--
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: Trouble understanding net config options

[Michael Jinks]

On Wed, Jul 15, 2009 at 6:35 PM, Andreas Plesner Jacobsena...@mutt.dk wrote:
 On Wed, Jul 15, 2009 at 06:22:56PM -0500, Michael Jinks wrote:


 I suppose that's a good sign, but it still leaves me wondering how to
 control which tap connects to which bridge, if I can't attach a guest
 to an existing tap.

 You can. Try adding script=no, so the kvm-ifup script does not get run.

Aha!  That answers my last question too.

Thanks!
--
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: Trouble understanding net config options

[Andreas Plesner Jacobsen]

On Thu, Jul 16, 2009 at 01:12:19AM +0200, Andreas Plesner Jacobsen wrote:
 
  I tried fd= instead of name=, but that looks for a file descriptor
  instead of a network interface name, and I didn't even know that Linux
  had file descriptors for network interfaces let alone how to map them
  to a tap.  Nothing under /dev looks promising.
 
  You need to add a vlan option to one of them, for example vlan=2
  Otherwise kvm will bridge the interfaces together, and it's going to  
  create a packet storm.
 
 Not if the tap-interfaces are connected to different bridges.

I'm sorry, I misunderstood your point. You're right.

-- 
Andreas
--
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: Trouble understanding net config options

[Chris Webb]

Michael Jinks michael.ji...@gmail.com writes:

 How do I make a guest use a specific tap?  Quoting
 from my initial post, my -net options are:
 
  -net nic -net tap,name=tap11 -net nic -net tap,name=tap12

You want

  -net nic,vlan=0 -net tap,vlan=0,ifname=tap11 -net nic,vlan=1 -net 
tap,vlan=1,ifname=tap12

to get the effect that (I think) you're looking for: one nic connected to
tap11 using vlan0 and one nic connected to tap12 using vlan1.

Without the vlan parameters, everything's on vlan0 so you get two nics and
two tap interfaces all connected together inside qemu on a single virtual
switch.

Best wishes,

Chris.
--
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: set_link monitor command

[Michael Jinks]

Another monitor command question: trying to rescue my de-networked
guest, I thought I'd try connecting to the console, but in its
monitor:

(qemu) info vnc
Server: disabled

According to the command line where I started this kvm instance, vnc
should be enabled.  Maybe it died?  Is there a way to turn it back on
again from the monitor?  I've looked but I can't find anything...



On Wed, Jul 15, 2009 at 6:30 PM, Michael Jinksmichael.ji...@gmail.com wrote:
 Like I said in my other network puzzlement thread, I have one KVM
 guest which is working fine.  Or, it was until I tried to add a second
 one, and hosed my virtual bridge.

 The guest is still running, but since I restarted the bridge interface
 that its NIC was attached to, it's no longer attached.  I thought that
 maybe bringing its network interface down and back up again might
 re-attach it to the bridge.  (Was I wrong?  Is there some other way to
 change the network connections for a running guest?)

 I found the set_link monitor command, but I can't figure out what
 the link name should be.  I've tried:

 (qemu) set_link eth0 up
 could not find network device 'eth0'(qemu)
 (qemu) set_link tap0 up
 could not find network device 'tap0'(qemu)

 ?

--
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: Trouble understanding net config options

[Charles Duffy]

Michael Jinks wrote:

On Wed, Jul 15, 2009 at 6:24 PM, Chris Webbch...@arachsys.com wrote:

You want

 -net nic,vlan=0 -net tap,vlan=0,ifname=tap11 -net nic,vlan=1 -net 
tap,vlan=1,ifname=tap12


Progress!  This works, I can bring up the guest and watch it boot, but
both of its NICs came up bound to the first bridge on the system.

I can work around that using 'brctl delif' and 'brctl addif' on the
host system, but how would I automate it so that, say, tap11 always
goes to br1, and tap12 always goes to br0?  I guess by taking out the
brctl in the kvm ifup script, and pre-setting all my bridge/tap
connections?


Use the script= argument on the -net tap,vlan=1 to use a qemu-ifup 
script which connects the tap device to the bridge you'd prefer be used.


--
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] rev3: support colon in filenames

[Anthony Liguori]

Jamie Lokier wrote:

So instead of consistency, you like the idea of using different
quoting rules for the monitor than for command line arguments?
  


Your proposal breaks Windows in a catastrophic way.  It's almost certain 
that all existing front-ends/scripts will stop working after such a change.


Or you have to quote differently on Windows which means you throw 
consistency out the Window.


I certainly like consistency but I don't see a viable proposal that 
offers that.


Regards,

Anthony Liguori


-- Jamie
--
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
  


--
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] Update KVM kernel module to allow a larger BIOS image.

[Jordan Justen]

Previously the KVM kernel module would allocate the address range
of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
This change moves that to 0xfeffc000-0xfeffcfff.

Another issue related to this change is the VMC TSS Pages were
located at 0xfffbd000-0xfffb.  This is controlled by the
qemu-kvm code.  A separate change will move them to
0xfeffd000-0xfeff.

From a high level, these are the effects of these two changes:

Previously, the KVM would only accommodate a 256KB BIOS image.  With
these changes, the BIOS image may now grow to 16MB.

Motivation for making these changes:

A larger firmware image size allows alternative BIOS images to be
used with KVM.  Some possible uses are to enable UEFI firmware
or coreboot firmware.  Additionally, an alternative firmware might
include a linux kernel+initrd payload, which would require several
megabytes.

Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
 arch/x86/include/asm/vmx.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 272514c..0086332 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -372,7 +372,7 @@ enum vmcs_field {
 #define VMX_EPT_EXECUTABLE_MASK0x4ull
 #define VMX_EPT_IGMT_BIT   (1ull  6)
 
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfeffc000ul
 
 
 #define ASM_VMX_VMCLEAR_RAX   .byte 0x66, 0x0f, 0xc7, 0x30
-- 
1.6.0.4

--
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] Update qemu-kvm to allow a larger BIOS image.

[Jordan Justen]

Previously the KVM kernel module would allocate the address range
of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
A separate patch is moving that to 0xfeffc000-0xfeffcfff.

This patch updates qemu-kvm to move the VMX TSS Pages  update the
KVM BIOS code to update the E820 BIOS call memory reservations.

Previously, the VMC TSS Pages were located at 0xfffbd000-0xfffb.
This change moved them to 0xfeffd000-0xfeff.

This change also updates the KVM bios such that the E820 locations
are returned properly for these two changes.

From a high level, these are the effects of these two changes:

Previously, the KVM would only accommodate a 256KB BIOS image.  With
these changes, the BIOS image may now grow to 16MB.

Motivation for making these changes:

A larger firmware image size allows alternative BIOS images to be
used with KVM.  Some possible uses are to enable UEFI firmware
or coreboot firmware.  Additionally, an alternative firmware might
include a linux kernel+initrd payload, which would require several
megabytes.

Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
 kvm/bios/rombios.c|8 
 kvm/include/x86/asm/vmx.h |2 +-
 qemu-kvm-x86.c|2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
index 6186199..2d0c153 100644
--- a/kvm/bios/rombios.c
+++ b/kvm/bios/rombios.c
@@ -4596,14 +4596,14 @@ ASM_END
 case 5:
 /* 4 pages before the bios, 3 pages for vmx tss pages,
 * the other page for EPT real mode pagetable */
-set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
-   0xfffcL, 0, 0, 2);
+set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
+   0xff00L, 0, 0, 2);
 regs.u.r32.ebx = 6;
 break;
 case 6:
-/* 256KB BIOS area at the end of 4 GB */
+/* 16MB BIOS area at the end of 4 GB */
 set_e820_range(ES, regs.u.r16.di,
-   0xfffcL, 0xL ,0, 0, 2);
+   0xff00L, 0xL ,0, 0, 2);
 if (extra_highbits_memory_size || 
extra_lowbits_memory_size)
 regs.u.r32.ebx = 7;
 else
diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
index df8d4f9..99e2bb9 100644
--- a/kvm/include/x86/asm/vmx.h
+++ b/kvm/include/x86/asm/vmx.h
@@ -403,7 +403,7 @@ enum vmcs_field {
 #define VMX_EPT_EXECUTABLE_MASK0x4ull
 #define VMX_EPT_IGMT_BIT   (1ull  6)
 
-#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfffbc000ul
+#define VMX_EPT_IDENTITY_PAGETABLE_ADDR0xfeffc000ul
 
 
 #define ASM_VMX_VMCLEAR_RAX   .byte 0x66, 0x0f, 0xc7, 0x30
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index daf60b6..b5306aa 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
 * this address is 3 pages before the bios, and the bios should 
present
 * as unavaible memory
 */
-   r = kvm_set_tss_addr(kvm, 0xfffbd000);
+   r = kvm_set_tss_addr(kvm, 0xfeffd000);
if (r  0) {
fprintf(stderr, kvm_init_tss: unable to set tss 
addr\n);
return r;
-- 
1.6.0.4

--
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

Mouse and keyboard handling on the VNC console

[Michael Jinks]

I'm not sure if I'm having VNC trouble, or KVM trouble.

I'm using vinagre as my VNC client, connecting to localhost.  Usually
I use TightVNC but Avi says it's broken, and it sure won't attach to a
QEMU server.

Both work fine if I connect to one of my own VNC servers (Linux).

Against a KVM console, mouse movement is erratic.  My console captures
the mouse, so I can't move it out of the window, but the far-side
pointer will freeze as though it's hitting the edge of a screen
(possibly because the near-side pointer actually is hitting the edge
of my vinagre window).  Sometimes by releasing the mouse and
recapturing, I can dance it around to the right part of the screen,
and sometimes not.

My arrow keys work sometimes.  For instance, during the setup of a
Solaris 10 guest, they work up to the point where I'm asked to choose
the file system type, and then they stop.  I was able to use the tab
key in some cases, but only to tab forward -- shift-tab doesn't
index backward, and if the OS installer doesn't happen to roll past
the end to the beginning of a list of fields, I'm stuck.

Now I'm trying to install a Windows guest, and the arrow keys don't
work at all.  tab and shift-tab both work as expected, but in cases
where the arrow keys are needed, like choosing the time zone, I'm
sunk.

Any idea what might be going on here?  Some other VNC client that
might work better, or a setting I can change somewhere?
--
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: Mouse and keyboard handling on the VNC console

[Michael Jinks]

After finishing some Windows guest setups, I've now discovered thet
vinagre's send ctl-alt-delete button doesn't work either.

I'm installing the old VNC package now, hoping it's better...


On Wed, Jul 15, 2009 at 7:24 PM, Michael Jinksmichael.ji...@gmail.com wrote:
 I'm not sure if I'm having VNC trouble, or KVM trouble.

 I'm using vinagre as my VNC client, connecting to localhost.  Usually
 I use TightVNC but Avi says it's broken, and it sure won't attach to a
 QEMU server.

 Both work fine if I connect to one of my own VNC servers (Linux).

 Against a KVM console, mouse movement is erratic.  My console captures
 the mouse, so I can't move it out of the window, but the far-side
 pointer will freeze as though it's hitting the edge of a screen
 (possibly because the near-side pointer actually is hitting the edge
 of my vinagre window).  Sometimes by releasing the mouse and
 recapturing, I can dance it around to the right part of the screen,
 and sometimes not.

 My arrow keys work sometimes.  For instance, during the setup of a
 Solaris 10 guest, they work up to the point where I'm asked to choose
 the file system type, and then they stop.  I was able to use the tab
 key in some cases, but only to tab forward -- shift-tab doesn't
 index backward, and if the OS installer doesn't happen to roll past
 the end to the beginning of a list of fields, I'm stuck.

 Now I'm trying to install a Windows guest, and the arrow keys don't
 work at all.  tab and shift-tab both work as expected, but in cases
 where the arrow keys are needed, like choosing the time zone, I'm
 sunk.

 Any idea what might be going on here?  Some other VNC client that
 might work better, or a setting I can change somewhere?

--
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] Update qemu-kvm to allow a larger BIOS image.

[Sheng Yang]

On Thursday 16 July 2009 08:12:15 Jordan Justen wrote:
 Previously the KVM kernel module would allocate the address range
 of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
 A separate patch is moving that to 0xfeffc000-0xfeffcfff.

Hi Jordan

You need one more patch for upstream kvm, to include the modification of 
vmx.h.

 This patch updates qemu-kvm to move the VMX TSS Pages  update the
 KVM BIOS code to update the E820 BIOS call memory reservations.

 Previously, the VMC TSS Pages were located at 0xfffbd000-0xfffb.
 This change moved them to 0xfeffd000-0xfeff.

 This change also updates the KVM bios such that the E820 locations
 are returned properly for these two changes.

 From a high level, these are the effects of these two changes:

 Previously, the KVM would only accommodate a 256KB BIOS image.  With
 these changes, the BIOS image may now grow to 16MB.

 Motivation for making these changes:

 A larger firmware image size allows alternative BIOS images to be
 used with KVM.  Some possible uses are to enable UEFI firmware
 or coreboot firmware.  Additionally, an alternative firmware might
 include a linux kernel+initrd payload, which would require several
 megabytes.

I think if you update bios to UEFI, the E820 should be represented by UEFI 
rather than current bios?

-- 
regards
Yang, Sheng

 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 ---
  kvm/bios/rombios.c|8 
  kvm/include/x86/asm/vmx.h |2 +-
  qemu-kvm-x86.c|2 +-
  3 files changed, 6 insertions(+), 6 deletions(-)

 diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
 index 6186199..2d0c153 100644
 --- a/kvm/bios/rombios.c
 +++ b/kvm/bios/rombios.c
 @@ -4596,14 +4596,14 @@ ASM_END
  case 5:
  /* 4 pages before the bios, 3 pages for vmx tss
 pages, * the other page for EPT real mode pagetable */
 -set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
 -   0xfffcL, 0, 0, 2);
 +set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
 +   0xff00L, 0, 0, 2);
  regs.u.r32.ebx = 6;
  break;
  case 6:
 -/* 256KB BIOS area at the end of 4 GB */
 +/* 16MB BIOS area at the end of 4 GB */
  set_e820_range(ES, regs.u.r16.di,
 -   0xfffcL, 0xL ,0, 0, 2);
 +   0xff00L, 0xL ,0, 0, 2);
  if (extra_highbits_memory_size ||
 extra_lowbits_memory_size) regs.u.r32.ebx = 7;
  else
 diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
 index df8d4f9..99e2bb9 100644
 --- a/kvm/include/x86/asm/vmx.h
 +++ b/kvm/include/x86/asm/vmx.h
 @@ -403,7 +403,7 @@ enum vmcs_field {
  #define VMX_EPT_EXECUTABLE_MASK  0x4ull
  #define VMX_EPT_IGMT_BIT (1ull  6)

 -#define VMX_EPT_IDENTITY_PAGETABLE_ADDR  0xfffbc000ul
 +#define VMX_EPT_IDENTITY_PAGETABLE_ADDR  0xfeffc000ul


  #define ASM_VMX_VMCLEAR_RAX   .byte 0x66, 0x0f, 0xc7, 0x30
 diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
 index daf60b6..b5306aa 100644
 --- a/qemu-kvm-x86.c
 +++ b/qemu-kvm-x86.c
 @@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
* this address is 3 pages before the bios, and the bios should 
 present
* as unavaible memory
*/
 - r = kvm_set_tss_addr(kvm, 0xfffbd000);
 + r = kvm_set_tss_addr(kvm, 0xfeffd000);
   if (r  0) {
   fprintf(stderr, kvm_init_tss: unable to set tss 
 addr\n);
   return r;


--
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] always report x2apic as supported feature

[Sheng Yang]

On Thursday 16 July 2009 07:01:30 Marcelo Tosatti wrote:
 On Sun, Jul 12, 2009 at 04:10:55PM +0300, Gleb Natapov wrote:
  We emulate x2apic in software, so host support is not required.
 
  Signed-off-by: Gleb Natapov g...@redhat.com
  diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
  index 00844eb..c256da7 100644
  --- a/arch/x86/kvm/x86.c
  +++ b/arch/x86/kvm/x86.c
  @@ -1497,6 +1497,9 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2
  *entry, u32 function, case 1:
  entry-edx = kvm_supported_word0_x86_features;
  entry-ecx = kvm_supported_word4_x86_features;
  +   /* we support x2apic emulation even if host does not support
  +  it since we emulate x2apic in software */
  +   entry-ecx |= F(X2APIC);
  break;
  /* function 2 entries are STATEFUL. That is, repeated cpuid commands
   * may return different values. This forces us to get_cpu() before
  --
  Gleb.

 What if you have an older host that does not support emulate x2apic?

Due to interrupt remapping can't be enabled with KVM now, I think older host 
would just ignore this info... (The new one can work without interrupt 
remapping with KVM).

By the way, I saw X2APIC in host supported CPUID feature list(1.ecx), which I 
don't think it's very properly. Host x2apic feature have nothing to do with 
KVM, we do the emulation all the way. I suggest to remove the mask for host, 
and give a comment that we would emulate all x2apic behaviour here, rather 
than even if, which I think it's a little misleading.

-- 
regards
Yang, Sheng

--
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: qcow2 relative paths (was: [PATCH] rev5: support colon in filenames)

[Ram Pai]

On Wed, 2009-07-15 at 22:04 +0100, Jamie Lokier wrote:
 Ram Pai wrote:
  I have successfully verified qcow2 files. But then I may not be trying
  out the exact thing that you are talking about. Can you give me a test 
  case that I can verify.
 
 Commands tried with qemu-0.10.0-1ubuntu1:
 
 $ mkdir unlikely_subdir
 $ cd unlikely_subdir
 $ qemu-img create -f qcow2 backing.img 10
 Formatting 'backing.img', fmt=qcow2, size=10 kB
 $ qemu-img create -f qcow2 -b ../unlikely_subdir/backing.img main.img 10
 Formatting 'main.img', fmt=qcow2, 
 backing_file=../unlikely_subdir/backing.img, size=10 kB
 $ cd ..
 $ qemu-img info unlikely_subdir/main.img 
 image: unlikely_subdir/main.img
 file format: qcow2
 virtual size: 10K (10240 bytes)
 disk size: 16K
 cluster_size: 4096
 highest_alloc: 16384
 backing file: ../unlikely_subdir/backing.img (actual path: 
 unlikely_subdir/../unlikely_subdir/backing.img)
 
 See especially the actual path line.
 
 $ mv unlikely_subdir other_subdir
 $ ls -l other_subdir
 total 32
 -rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 backing.img
 -rw-r--r-- 1 jamie jamie 16384 2009-07-15 21:59 main.img
 $ qemu-img info other_subdir/main.img 
 qemu-img: Could not open 'other_subdir/main.img'

Turns out that I did introduce a bug by deleting the call
to path_combine() before calling bdrv_open() on the backing
filename. However the call to realpath() is still not needed.
It feels like a kludge introduced to stop path_combine() from
munging backing_filename. 

I will send out yet another revision with the fix. I just dont' know
what else I will be breaking without having a regression test
harness. :( 


 
 What an unhelpful error message...  There isn't even a way to find out
 the backing file path which the tool is looking for.

Ok. i have introduced a message towards the effect, in the next revision
of the patch.  Hope that will make things a little easier.

I have to go through the all the other mails to understand what has been
proposed, and what I need to incorporate. Looks like a tall order.

For now i will send out revision 6 in the next few hours.

RP


 
  And one other thing. Let me know if there a test-suite that I can try
  for regressions.
 
 Sorry, I don't know anything about any QEMU test suites.
 
 -- Jamie

RP

--
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: [Autotest] [PATCH] Assign an UUID for each VM in kvm command line

[Yolkfull Chow]

On 07/15/2009 09:36 PM, Dor Laor wrote:

On 07/15/2009 12:12 PM, Yolkfull Chow wrote:
Would submit this patch which is from our internal kvm-autotest 
patches submitted by Jason.
So that we could go on test case about parameters verification(UUID, 
DMI data etc).


Signed-off-by: Yolkfull Chowyz...@redhat.com
---
  client/tests/kvm/kvm_vm.py |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
index 503f636..68cc235 100644
--- a/client/tests/kvm/kvm_vm.py
+++ b/client/tests/kvm/kvm_vm.py
@@ -287,6 +287,10 @@ class VM:
  elif params.get(display) == nographic:
  qemu_cmd +=  -nographic

+uuid = os.popen(cat 
/proc/sys/kernel/random/uuid).readline().strip()

+if uuid:
+qemu_cmd +=  -uuid %s % uuid


If you'll change the uuid on every run, the guest will notice that. 
Some guest (M$) might not love it.
Why not use a static uuid or even just test uuid in a specific test 
without having it in all tests?
Hi Dor, since we cannot use a static uuid for running stress_boot test, 
but just assign UUID in a specific test is a good idea. We could use an 
option like assign_uuid = yes for that specific test?


btw: why you're at it, please add uuid to the block devices too.
+ the -smbios option.

Do you mean assign serial number for block devices?

Thanks for suggestions. :)


Thanks,
dor


+
  return qemu_cmd







--
Yolkfull
Regards,

--
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] Update qemu-kvm to allow a larger BIOS image.

[Jordan Justen]

On Wed, Jul 15, 2009 at 6:34 PM, Sheng Yang sh...@linux.intel.com wrote:

 On Thursday 16 July 2009 08:12:15 Jordan Justen wrote:
  Previously the KVM kernel module would allocate the address range
  of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
  A separate patch is moving that to 0xfeffc000-0xfeffcfff.

 Hi Jordan

 You need one more patch for upstream kvm, to include the modification of
 vmx.h.

I sent a separate patch for vmx.h for the
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tree.  Do I
need a patch for another copy of vmx.h?

 
  This patch updates qemu-kvm to move the VMX TSS Pages  update the
  KVM BIOS code to update the E820 BIOS call memory reservations.
 
  Previously, the VMC TSS Pages were located at 0xfffbd000-0xfffb.
  This change moved them to 0xfeffd000-0xfeff.
 
  This change also updates the KVM bios such that the E820 locations
  are returned properly for these two changes.
 
  From a high level, these are the effects of these two changes:
 
  Previously, the KVM would only accommodate a 256KB BIOS image.  With
  these changes, the BIOS image may now grow to 16MB.
 
  Motivation for making these changes:
 
  A larger firmware image size allows alternative BIOS images to be
  used with KVM.  Some possible uses are to enable UEFI firmware
  or coreboot firmware.  Additionally, an alternative firmware might
  include a linux kernel+initrd payload, which would require several
  megabytes.

 I think if you update bios to UEFI, the E820 should be represented by UEFI
 rather than current bios?

Yeah, that is true.  But, that firmware would be separate from the qemu-kvm
tree at this time, right?

But, in this patch it is critical that the 'VMX TSS Pages' are moved within
qemu-kvm so the conflict with the larger bios.bin is removed.


 --
 regards
 Yang, Sheng

  Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
  ---
   kvm/bios/rombios.c        |    8 
   kvm/include/x86/asm/vmx.h |    2 +-
   qemu-kvm-x86.c            |    2 +-
   3 files changed, 6 insertions(+), 6 deletions(-)
 
  diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
  index 6186199..2d0c153 100644
  --- a/kvm/bios/rombios.c
  +++ b/kvm/bios/rombios.c
  @@ -4596,14 +4596,14 @@ ASM_END
                       case 5:
                           /* 4 pages before the bios, 3 pages for vmx tss
  pages, * the other page for EPT real mode pagetable */
  -                        set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
  -                                       0xfffcL, 0, 0, 2);
  +                        set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
  +                                       0xff00L, 0, 0, 2);
                           regs.u.r32.ebx = 6;
                           break;
                       case 6:
  -                        /* 256KB BIOS area at the end of 4 GB */
  +                        /* 16MB BIOS area at the end of 4 GB */
                           set_e820_range(ES, regs.u.r16.di,
  -                                       0xfffcL, 0xL ,0, 0, 2);
  +                                       0xff00L, 0xL ,0, 0, 2);
                           if (extra_highbits_memory_size ||
  extra_lowbits_memory_size) regs.u.r32.ebx = 7;
                           else
  diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
  index df8d4f9..99e2bb9 100644
  --- a/kvm/include/x86/asm/vmx.h
  +++ b/kvm/include/x86/asm/vmx.h
  @@ -403,7 +403,7 @@ enum vmcs_field {
   #define VMX_EPT_EXECUTABLE_MASK                      0x4ull
   #define VMX_EPT_IGMT_BIT                     (1ull  6)
 
  -#define VMX_EPT_IDENTITY_PAGETABLE_ADDR              0xfffbc000ul
  +#define VMX_EPT_IDENTITY_PAGETABLE_ADDR              0xfeffc000ul
 
 
   #define ASM_VMX_VMCLEAR_RAX       .byte 0x66, 0x0f, 0xc7, 0x30
  diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
  index daf60b6..b5306aa 100644
  --- a/qemu-kvm-x86.c
  +++ b/qemu-kvm-x86.c
  @@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
                 * this address is 3 pages before the bios, and the bios 
  should present
                 * as unavaible memory
                 */
  -             r = kvm_set_tss_addr(kvm, 0xfffbd000);
  +             r = kvm_set_tss_addr(kvm, 0xfeffd000);
                if (r  0) {
                        fprintf(stderr, kvm_init_tss: unable to set tss 
  addr\n);
                        return r;


 --
 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
--
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: Mouse and keyboard handling on the VNC console

[Michael Jinks]

On Wed, Jul 15, 2009 at 8:04 PM, Michael Jinksmichael.ji...@gmail.com wrote:

 I'm installing the old VNC package now, hoping it's better...

Nope, it's worse.  Carries the same sort of failure to connect that I
saw with TightVNC, immediate failure and Rect too big to stderr.

Has the world moved to some other set of VNC clients when I wasn't
paying attention?  Searching my Linux distro's package list for VNC
alternatives isn't turning up anything but VNC, TightVNC, and Vinagre,
but it's possible I just don't know the right search string to use.
--
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] Update qemu-kvm to allow a larger BIOS image.

[Sheng Yang]

On Thursday 16 July 2009 10:58:53 Jordan Justen wrote:
 On Wed, Jul 15, 2009 at 6:34 PM, Sheng Yang sh...@linux.intel.com wrote:
  On Thursday 16 July 2009 08:12:15 Jordan Justen wrote:
   Previously the KVM kernel module would allocate the address range
   of 0xfffbc000-0xfffbcfff for the EPT Indentity Page Tables.
   A separate patch is moving that to 0xfeffc000-0xfeffcfff.
 
  Hi Jordan
 
  You need one more patch for upstream kvm, to include the modification of
  vmx.h.

 I sent a separate patch for vmx.h for the
 git://git.kernel.org/pub/scm/virt/kvm/kvm.git tree.  Do I
 need a patch for another copy of vmx.h?

Oh, sorry, overlook that one...(I just think the second one is a update to the 
first...) :(

   This patch updates qemu-kvm to move the VMX TSS Pages  update the
   KVM BIOS code to update the E820 BIOS call memory reservations.
  
   Previously, the VMC TSS Pages were located at 0xfffbd000-0xfffb.
   This change moved them to 0xfeffd000-0xfeff.
  
   This change also updates the KVM bios such that the E820 locations
   are returned properly for these two changes.
  
   From a high level, these are the effects of these two changes:
  
   Previously, the KVM would only accommodate a 256KB BIOS image.  With
   these changes, the BIOS image may now grow to 16MB.
  
   Motivation for making these changes:
  
   A larger firmware image size allows alternative BIOS images to be
   used with KVM.  Some possible uses are to enable UEFI firmware
   or coreboot firmware.  Additionally, an alternative firmware might
   include a linux kernel+initrd payload, which would require several
   megabytes.
 
  I think if you update bios to UEFI, the E820 should be represented by
  UEFI rather than current bios?

 Yeah, that is true.  But, that firmware would be separate from the qemu-kvm
 tree at this time, right?

Yes, so currently from QEmu-kvm side, I think it may not necessary to update, 
for the patches haven't followed up yet...

 But, in this patch it is critical that the 'VMX TSS Pages' are moved within
 qemu-kvm so the conflict with the larger bios.bin is removed.

Well, for we are using a small size bios now, and larger bios would be totally 
another story, I don't think push the modification now to the upstream make 
sense. These modification can go with further patches with UEFI at any time in 
the future.

-- 
regards
Yang, Sheng


  --
  regards
  Yang, Sheng
 
   Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
   ---
kvm/bios/rombios.c|8 
kvm/include/x86/asm/vmx.h |2 +-
qemu-kvm-x86.c|2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
  
   diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
   index 6186199..2d0c153 100644
   --- a/kvm/bios/rombios.c
   +++ b/kvm/bios/rombios.c
   @@ -4596,14 +4596,14 @@ ASM_END
case 5:
/* 4 pages before the bios, 3 pages for vmx
   tss pages, * the other page for EPT real mode pagetable */
   -set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
   -   0xfffcL, 0, 0, 2);
   +set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
   +   0xff00L, 0, 0, 2);
regs.u.r32.ebx = 6;
break;
case 6:
   -/* 256KB BIOS area at the end of 4 GB */
   +/* 16MB BIOS area at the end of 4 GB */
set_e820_range(ES, regs.u.r16.di,
   -   0xfffcL, 0xL ,0, 0,
   2); +   0xff00L, 0xL
   ,0, 0, 2); if (extra_highbits_memory_size ||
   extra_lowbits_memory_size) regs.u.r32.ebx = 7;
else
   diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
   index df8d4f9..99e2bb9 100644
   --- a/kvm/include/x86/asm/vmx.h
   +++ b/kvm/include/x86/asm/vmx.h
   @@ -403,7 +403,7 @@ enum vmcs_field {
#define VMX_EPT_EXECUTABLE_MASK  0x4ull
#define VMX_EPT_IGMT_BIT (1ull  6)
  
   -#define VMX_EPT_IDENTITY_PAGETABLE_ADDR  0xfffbc000ul
   +#define VMX_EPT_IDENTITY_PAGETABLE_ADDR  0xfeffc000ul
  
  
#define ASM_VMX_VMCLEAR_RAX   .byte 0x66, 0x0f, 0xc7, 0x30
   diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
   index daf60b6..b5306aa 100644
   --- a/qemu-kvm-x86.c
   +++ b/qemu-kvm-x86.c
   @@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
  * this address is 3 pages before the bios, and the bios
   should present * as unavaible memory
  */
   - r = kvm_set_tss_addr(kvm, 0xfffbd000);
   + r = kvm_set_tss_addr(kvm, 0xfeffd000);
 if (r  0) {
 fprintf(stderr, kvm_init_tss: unable to set tss
   addr\n); 

Re: [Autotest] [PATCH] Assign an UUID for each VM in kvm command line

[sudhir kumar]

On Thu, Jul 16, 2009 at 8:12 AM, Yolkfull Chowyz...@redhat.com wrote:
 On 07/15/2009 09:36 PM, Dor Laor wrote:
 On 07/15/2009 12:12 PM, Yolkfull Chow wrote:
 Would submit this patch which is from our internal kvm-autotest
 patches submitted by Jason.
 So that we could go on test case about parameters verification(UUID,
 DMI data etc).

 Signed-off-by: Yolkfull Chowyz...@redhat.com
 ---
   client/tests/kvm/kvm_vm.py |    4 
   1 files changed, 4 insertions(+), 0 deletions(-)

 diff --git a/client/tests/kvm/kvm_vm.py b/client/tests/kvm/kvm_vm.py
 index 503f636..68cc235 100644
 --- a/client/tests/kvm/kvm_vm.py
 +++ b/client/tests/kvm/kvm_vm.py
 @@ -287,6 +287,10 @@ class VM:
           elif params.get(display) == nographic:
               qemu_cmd +=  -nographic

 +        uuid = os.popen(cat
 /proc/sys/kernel/random/uuid).readline().strip()
 +        if uuid:
 +            qemu_cmd +=  -uuid %s % uuid

 If you'll change the uuid on every run, the guest will notice that.
 Some guest (M$) might not love it.
 Why not use a static uuid or even just test uuid in a specific test
 without having it in all tests?
 Hi Dor, since we cannot use a static uuid for running stress_boot test,
 but just assign UUID in a specific test is a good idea. We could use an
 option like assign_uuid = yes for that specific test?

This will be far better and more flexible.

 btw: why you're at it, please add uuid to the block devices too.
 + the -smbios option.
 Do you mean assign serial number for block devices?

 Thanks for suggestions. :)

 Thanks,
 dor

 +
           return qemu_cmd





 --
 Yolkfull
 Regards,

 ___
 Autotest mailing list
 autot...@test.kernel.org
 http://test.kernel.org/cgi-bin/mailman/listinfo/autotest




-- 
Sudhir Kumar
--
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: [Autotest] [RFC] KVM-Autotest: remote shell utility for Windows guests

[sudhir kumar]

Thats great Michael !!

On Wed, Jul 15, 2009 at 8:56 PM, Michael Goldishmgold...@redhat.com wrote:

 - Lucas Meneghel Rodrigues l...@redhat.com wrote:

 On Wed, Jul 8, 2009 at 4:46 AM, Michael Goldishmgold...@redhat.com
 wrote:
  I'm resending the message because it probably got filtered out due
 to the
  attached setup.bat file.
 
  The contents of setup.bat were:
 
  copy D:\rss.exe C:\
 
  net user Administrator /active:yes
  net user Administrator 1q2w3eP
  netsh firewall set opmode disable
 
  reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v
 Remote Shell Server /d C:\rss.exe 22 /t REG_SZ /f
  reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon
 /v AutoAdminLogon /d 1 /t REG_SZ /f
  reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon
 /v DefaultUserName /d Administrator /t REG_SZ /f
  reg add HKLM\Software\Microsoft\Windows NT\CurrentVersion\winlogon
 /v DefaultPassword /d 1q2w3eP /t REG_SZ /f
 
  - Original Message -
 
  Hi,
 
  In an attempt to solve the SSH problems we have with Windows, I
 wrote a little
  remote shell utility to replace the OpenSSH server we're currently
 using with
  Win(2000|XP|2003) and the builtin Telnet server we're using with
 Win2008.
  It also works with Vista, for which we currently have no other
 solution.

 This is a very welcome addition to our test tools, for sure.

 
  Features:
  - Listens on a requested port (22 by default).
  - Provides clients with a cmd.exe shell.
So does it export the full environment of cmd.exe ? I meant can we run
all the commands here as we can do in a direct cmd.exe in a windows
system?

  - Multiple clients can connect simultaneously.
  - Uses no authentication whatsoever.
  - Uses standard API calls that should work on all modern Windows
 variants.
  - Displays an informative message box if any API call fails.
  - Automatically closes all processes started by a client when it
 disconnects.
  - Allows clients to run GUI programs (see comment below).
  - Starts minimized by default so it doesn't interfere with step file
 tests.
  - Reports all activity in a text box.
  - The code is short (450 lines including comments).

 I definitely like that :)

 
  Tested and verified to work on WinXP 32, 2003 32, Vista 32 and 64,
 2008 32.
  I haven't tested it on other Windows versions but it should work
 (should be
I can give a quick testing on some of the datacentres if I can get the binaries.

  interesting to test it on Windows 7).
 
  The source code is attached.  I used MinGW (with Code::Blocks) to
 compile it
  under WinXP.  Link it with ws2_32.lib.  If anyone wants the binary
 please let
  me know and I'll send it somehow (I don't know if I'm supposed to
 send
  binaries to the list).
Yes please.
May be in future the binaries can be hosted somewhere and we can add
the steps files to do an automatic install of the ssh server on the
windows guests ?
 
 
  Problems:
  - cmd.exe echoes back the command line sent to it.  This means
 commands are
  echoed twice: first by the local terminal and then by the remote
 cmd.exe.
  So if you send ver\r\n to the server you get:
  ver\r\nver\r\nMicrosoft Windows [Version ...]\r\nC:\\
  In order for it to work with Autotest we'll have to make some
 modifications
  to kvm_utils.kvm_spawn (which should be replaced by kvm_subprocess
 anyway) --
  specifically disable the local terminal echo, and not assume that
 the command
  line is echoed exactly once (it may not be echoed at all by Linux
 guests).
 
  - The server does not send or receive files.  For now we can
 transfer files
  into Windows guests using ISOs (-cdrom).  If it turns out to be
 necessary, file
  send/receive support can be implemented into the shell server, or we
 can use an
  open source Windows FTP server or find some other solution.

 Yes, a remote copy utility would be good, in order to keep
 consistency.
That too if it can be implemented in the same shell server will be
good in comparison to relying on multiple tools/utilities.

  - Running GUI apps: Vista and 2008 seem to run GUI apps just fine
 from a remote
  shell, but in older Windows versions you must use cmd /c
  (e.g. cmd /c notepad).

  To be compatible with all Windows versions, Windows GUI tests should
 probably
  always use cmd /c to run GUI apps.  There's no need to use it for
 console
  commands (e.g. dir).

  Note that when using cmd /c the command returns only when the GUI
 app exits.
  Without cmd /c the command returns immediately.
 
  - Some interactive console programs don't behave nicely when their
 output is
  redirected (to a remote client in this case).  One example is the
 builtin
  ftp.exe.  If you want to use it, you should do so without waiting
 for
  interactive output from the program, which means you should just
 send the FTP
  commands one by one and hope everything works, and finally send a
 'quit'
  command to get back to cmd.exe.
 
 
  Installation on guests:
  The following should be done as a 

Re: [PATCH] Update qemu-kvm to allow a larger BIOS image.

[Jordan Justen]

On Wed, Jul 15, 2009 at 8:08 PM, Sheng Yangsh...@linux.intel.com wrote:
 On Thursday 16 July 2009 10:58:53 Jordan Justen wrote:
 On Wed, Jul 15, 2009 at 6:34 PM, Sheng Yang sh...@linux.intel.com wrote:
  On Thursday 16 July 2009 08:12:15 Jordan Justen wrote:
  
   Motivation for making these changes:
  
   A larger firmware image size allows alternative BIOS images to be
   used with KVM.  Some possible uses are to enable UEFI firmware
   or coreboot firmware.  Additionally, an alternative firmware might
   include a linux kernel+initrd payload, which would require several
   megabytes.
 
  I think if you update bios to UEFI, the E820 should be represented by
  UEFI rather than current bios?

 Yeah, that is true.  But, that firmware would be separate from the qemu-kvm
 tree at this time, right?

 Yes, so currently from QEmu-kvm side, I think it may not necessary to update,
 for the patches haven't followed up yet...

Of the two patches (1. kvm kernel module, 2. qemu-kvm), I think it
is best if the qemu-kvm change happens first.  Since the qemu-kvm
patch will cause the qemu-kvm bios to add more memory regions
as reserved, the new change to qemu-kvm will be compatible with
both the old and new versions of the kvm kernel module.

 But, in this patch it is critical that the 'VMX TSS Pages' are moved within
 qemu-kvm so the conflict with the larger bios.bin is removed.

 Well, for we are using a small size bios now, and larger bios would be totally
 another story, I don't think push the modification now to the upstream make
 sense. These modification can go with further patches with UEFI at any time in
 the future.

I am working on this UEFI firmware project which currently supports QEMU:
https://edk2.tianocore.org/OVMF.html

I would like it to also support KVM, and I found that it can already boot the
UEFI shell on KVM if these two patches are applied.

If these patches make some progress, I will update OVMF to reserve the
appropriate memory regions.

 --
 regards
 Yang, Sheng


  --
  regards
  Yang, Sheng
 
   Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
   ---
    kvm/bios/rombios.c        |    8 
    kvm/include/x86/asm/vmx.h |    2 +-
    qemu-kvm-x86.c            |    2 +-
    3 files changed, 6 insertions(+), 6 deletions(-)
  
   diff --git a/kvm/bios/rombios.c b/kvm/bios/rombios.c
   index 6186199..2d0c153 100644
   --- a/kvm/bios/rombios.c
   +++ b/kvm/bios/rombios.c
   @@ -4596,14 +4596,14 @@ ASM_END
                        case 5:
                            /* 4 pages before the bios, 3 pages for vmx
   tss pages, * the other page for EPT real mode pagetable */
   -                        set_e820_range(ES, regs.u.r16.di, 0xfffbc000L,
   -                                       0xfffcL, 0, 0, 2);
   +                        set_e820_range(ES, regs.u.r16.di, 0xfeffc000L,
   +                                       0xff00L, 0, 0, 2);
                            regs.u.r32.ebx = 6;
                            break;
                        case 6:
   -                        /* 256KB BIOS area at the end of 4 GB */
   +                        /* 16MB BIOS area at the end of 4 GB */
                            set_e820_range(ES, regs.u.r16.di,
   -                                       0xfffcL, 0xL ,0, 0,
   2); +                                       0xff00L, 0xL
   ,0, 0, 2); if (extra_highbits_memory_size ||
   extra_lowbits_memory_size) regs.u.r32.ebx = 7;
                            else
   diff --git a/kvm/include/x86/asm/vmx.h b/kvm/include/x86/asm/vmx.h
   index df8d4f9..99e2bb9 100644
   --- a/kvm/include/x86/asm/vmx.h
   +++ b/kvm/include/x86/asm/vmx.h
   @@ -403,7 +403,7 @@ enum vmcs_field {
    #define VMX_EPT_EXECUTABLE_MASK                      0x4ull
    #define VMX_EPT_IGMT_BIT                     (1ull  6)
  
   -#define VMX_EPT_IDENTITY_PAGETABLE_ADDR              0xfffbc000ul
   +#define VMX_EPT_IDENTITY_PAGETABLE_ADDR              0xfeffc000ul
  
  
    #define ASM_VMX_VMCLEAR_RAX       .byte 0x66, 0x0f, 0xc7, 0x30
   diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
   index daf60b6..b5306aa 100644
   --- a/qemu-kvm-x86.c
   +++ b/qemu-kvm-x86.c
   @@ -63,7 +63,7 @@ static int kvm_init_tss(kvm_context_t kvm)
                  * this address is 3 pages before the bios, and the bios
   should present * as unavaible memory
                  */
   -             r = kvm_set_tss_addr(kvm, 0xfffbd000);
   +             r = kvm_set_tss_addr(kvm, 0xfeffd000);
                 if (r  0) {
                         fprintf(stderr, kvm_init_tss: unable to set tss
   addr\n); return r;
 
  --
  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

 --
 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