date:20120311

[Qemu-devel] [PATCH] ide: Adds model=s option, allowing the user to override the default disk model name QEMU HARDDISK

2012-03-11 Thread Floris Bos

Some Linux distributions use the 
/dev/disk/by-id/scsi-SATA_name-of-disk-model_serial addressing scheme
when refering to partitions in /etc/fstab and elsewhere.
This causes problems when starting a disk image taken from an existing physical 
server under qemu,
because when running under qemu name-of-disk-model is always QEMU HARDDISK
This patch introduces a model=s option which in combination with the existing 
serial=s option can be used to
fake the disk the operating system was previously on, allowing the OS to boot 
properly.

Cc: kw...@redhat.com
Signed-off-by: Floris Bos d...@noc-ps.com
---
 blockdev.c|4 
 blockdev.h|2 ++
 hw/ide/core.c |   27 ++-
 hw/ide/internal.h |4 +++-
 hw/ide/qdev.c |   17 +++--
 qemu-config.c |4 
 qemu-options.hx   |4 +++-
 7 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index d78aa51..66fcc14 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -277,6 +277,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 const char *file = NULL;
 char devname[128];
 const char *serial;
+const char *model;
 const char *mediastr = ;
 BlockInterfaceType type;
 enum { MEDIA_DISK, MEDIA_CDROM } media;
@@ -313,6 +314,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 
 file = qemu_opt_get(opts, file);
 serial = qemu_opt_get(opts, serial);
+model = qemu_opt_get(opts, model);
 
 if ((buf = qemu_opt_get(opts, if)) != NULL) {
 pstrcpy(devname, sizeof(devname), buf);
@@ -534,6 +536,8 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 dinfo-refcount = 1;
 if (serial)
 strncpy(dinfo-serial, serial, sizeof(dinfo-serial) - 1);
+if (model)
+strncpy(dinfo-model, model, sizeof(dinfo-model) - 1);
 QTAILQ_INSERT_TAIL(drives, dinfo, next);
 
 bdrv_set_on_error(dinfo-bdrv, on_read_error, on_write_error);
diff --git a/blockdev.h b/blockdev.h
index 260e16b..21eb4b5 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -18,6 +18,7 @@ void blockdev_mark_auto_del(BlockDriverState *bs);
 void blockdev_auto_del(BlockDriverState *bs);
 
 #define BLOCK_SERIAL_STRLEN 20
+#define BLOCK_MODEL_STRLEN 40
 
 typedef enum {
 IF_DEFAULT = -1,/* for use with drive_add() only */
@@ -37,6 +38,7 @@ struct DriveInfo {
 int media_cd;
 QemuOpts *opts;
 char serial[BLOCK_SERIAL_STRLEN + 1];
+char model[BLOCK_MODEL_STRLEN + 1];
 QTAILQ_ENTRY(DriveInfo) next;
 int refcount;
 };
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 4d568ac..2a38030 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -101,7 +101,7 @@ static void ide_identify(IDEState *s)
 put_le16(p + 21, 512); /* cache size in sectors */
 put_le16(p + 22, 4); /* ecc bytes */
 padstr((char *)(p + 23), s-version, 8); /* firmware version */
-padstr((char *)(p + 27), QEMU HARDDISK, 40); /* model */
+padstr((char *)(p + 27), s-drive_model_str, 40); /* model */
 #if MAX_MULT_SECTORS  1
 put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);
 #endif
@@ -189,7 +189,7 @@ static void ide_atapi_identify(IDEState *s)
 put_le16(p + 21, 512); /* cache size in sectors */
 put_le16(p + 22, 4); /* ecc bytes */
 padstr((char *)(p + 23), s-version, 8); /* firmware version */
-padstr((char *)(p + 27), QEMU DVD-ROM, 40); /* model */
+padstr((char *)(p + 27), s-drive_model_str, 40); /* model */
 put_le16(p + 48, 1); /* dword I/O (XXX: should not be set on CDROM) */
 #ifdef USE_DMA_CDROM
 put_le16(p + 49, 1  9 | 1  8); /* DMA and LBA supported */
@@ -246,7 +246,7 @@ static void ide_cfata_identify(IDEState *s)
 padstr((char *)(p + 10), s-drive_serial_str, 20); /* serial number */
 put_le16(p + 22, 0x0004);  /* ECC bytes */
 padstr((char *) (p + 23), s-version, 8);  /* Firmware Revision */
-padstr((char *) (p + 27), QEMU MICRODRIVE, 40);/* Model number */
+padstr((char *) (p + 27), s-drive_model_str, 40);/* Model number */
 #if MAX_MULT_SECTORS  1
 put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);
 #else
@@ -1834,7 +1834,7 @@ static const BlockDevOps ide_cd_block_ops = {
 };
 
 int ide_init_drive(IDEState *s, BlockDriverState *bs, IDEDriveKind kind,
-   const char *version, const char *serial)
+   const char *version, const char *serial, const char *model)
 {
 int cylinders, heads, secs;
 uint64_t nb_sectors;
@@ -1885,6 +1885,22 @@ int ide_init_drive(IDEState *s, BlockDriverState *bs, 
IDEDriveKind kind,
 snprintf(s-drive_serial_str, sizeof(s-drive_serial_str),
  QM%05d, s-drive_serial);
 }
+if (model) {
+strncpy(s-drive_model_str, model, sizeof(s-drive_model_str));
+} else {
+switch (kind) {
+case IDE_CD:
+strcpy(s-drive_model_str, QEMU DVD-ROM);
+break;
+case IDE_CFATA:
+

[Qemu-devel] How to trace all the guest OS instructions and the micro-ops

2012-03-11 Thread Yue Chen

Hi!

I am doing some research based on the QEMU. Does anyone know how to get
(trace) all the instructions of the guest OS, and get all the intermediate
micro-ops ?  (Not in the 0.9.1 version)

Additionally, how to get the whole memory or each process' memory data of
the guest OS?

I really appreciate your help.

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

2012-03-11 Thread Andrew Cathrow

- Original Message -
From: Anthony Liguori anth...@codemonkey.ws
To: Daniel P. Berrange berra...@redhat.com, libvir-l...@redhat.com,
qemu-devel@nongnu.org, Gleb Natapov
g...@redhat.com, Jiri Denemark jdene...@redhat.com, Avi Kivity
a...@redhat.com, a...@ovirt.org
Sent: Saturday, March 10, 2012 1:24:47 PM
Subject: Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with
libvirt

On 03/10/2012 09:58 AM, Eduardo Habkost wrote:
On Sat, Mar 10, 2012 at 12:42:46PM +, Daniel P. Berrange wrote:

I could have sworn we had this discussion a year ago or so, and
had decided
that the default CPU models would be in something like
/usr/share/qemu/cpu-x86_64.conf
and loaded regardless of the -nodefconfig setting.
/etc/qemu/target-x86_64.conf
would be solely for end user configuration changes, not for QEMU
builtin
defaults.

But looking at the code in QEMU, it doesn't seem we ever
implemented this ?

Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu
RPMs but,
contrary to our normal RHEL development practice, it was not based
on
a cherry-pick of an upstream patch :-(

For sake of reference, I'm attaching the two patches from the
RHEL6 source
RPM that do what I'm describing

NB, I'm not neccessarily advocating these patches for upstream. I
still
maintain that libvirt should write out a config file containing
the
exact CPU model description it desires and specify that with
-readconfig.
The end result would be identical from QEMU's POV and it would
avoid
playing games with QEMU's config loading code.

I agree that libvirt should just write the config somewhere. The
problem
here is to define: 1) what information should be mandatory on that
config data; 2) who should be responsible to test and maintain sane
defaults (and where should they be maintained).

The current cpudef definitions are simply too low-level to require
it to
be written from scratch. Lots of testing have to be done to make
sure we
have working combinations of CPUID bits defined, so they can be
used as
defaults or templates. Not facilitating reuse of those tested
defauls/templates by libvirt is duplication of efforts.

Really, if we expect libvirt to define all the CPU bits from
scratch on
a config file, we could as well just expect libvirt to open
/dev/kvm
itself and call the all CPUID setup ioctl()s itself. That's how
low-level some of the cpudef bits are.

Let's step back here.

Why are you writing these patches? It's probably not because you
have a desire
to say -cpu Westmere when you run QEMU on your laptop. I'd wager to
say that no
human has ever done that or that if they had, they did so by accident
because
they read documentation and thought they had to.

Humans probably do one of two things: 1) no cpu option or 2) -cpu
host.

So then why are you introducing -cpu Westmere? Because ovirt-engine
has a
concept of datacenters and the entire datacenter has to use a
compatible CPU
model to allow migration compatibility. Today, the interface that
ovirt-engine
exposes is based on CPU codenames. Presumably ovirt-engine wants to
add a
Westmere CPU group and as such have levied a requirement down the
stack to QEMU.

But there's no intrinsic reason why it uses CPU model names. VMware
doesn't do
this. It has a concept of compatibility groups[1].

s/has/had

That was back in the 3.5 days and it was hit and miss, it relied on a user
putting the same kind of machines in the resource groups and often caused
issues.
Now they've moved up to a model very similar to what we're using:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1003212

oVirt could just as well define compatibility groups like GroupA,
GroupB,
GroupC, etc. and then the -cpu option we would be discussing would be
-cpu GroupA.

This is why it's a configuration option and not builtin to QEMU.
It's a user
interface as as such, should be defined at a higher level.

Perhaps it really should be VDSM that is providing the model info to
libvirt?
Then they can add whatever groups then want whenever they want as
long as we
have the appropriate feature bits.

I think the real (model specific) names are the best place to start.
But if a user wants to override those with their own specific types then it
should be allowed

P.S. I spent 30 minutes the other day helping a user who was
attempting to
figure out whether his processor was a Conroe, Penryn, etc. Making
this
determination is fairly difficult and it makes me wonder whether
having CPU code
names is even the best interface for oVirt..

I think that was more about a bad choice in UI than a bad choice in the
architecture.
It should be made clear to a user what kind of machine they have and what it's
capabilities are
This bug was borne out of that issue

Re: [Qemu-devel] [PATCH 1/2] Support @documentencoding in scripts/texi2pod.pl

2012-03-11 Thread Michael Tokarev

Ping?  It's been more than a month since this patch has been posted.

Maybe it is a good candidate for -trivial queue?

Thanks,

/mjt

On 02.02.2012 18:16, Michael Tokarev wrote:
 Currently our texi2pod ignores @documentencoding even if it is set
 properly in *.texi files.  This results in a mojibake in documents
 generated from qemu.pod (which is generated from qemu-doc.texi by
 texi2pod), because the rest of the tools assumes ASCII encoding.
 
 This patch recognizes first @documentencoding in input and places
 it at the beginning of output as =encoding directive.
 
 Signed-Off-By: Michael Tokarev m...@tls.msk.ru
 ---
  scripts/texi2pod.pl |9 +
  1 files changed, 9 insertions(+), 0 deletions(-)
 
 diff --git a/scripts/texi2pod.pl b/scripts/texi2pod.pl
 index 9ed056a..94097fb 100755
 --- a/scripts/texi2pod.pl
 +++ b/scripts/texi2pod.pl
 @@ -36,6 +36,7 @@ $fnno = 1;
  $inf = ;
  $ibase = ;
  @ipath = ();
 +$encoding = undef;
  
  while ($_ = shift) {
  if (/^-D(.*)$/) {
 @@ -97,6 +98,12 @@ while($inf) {
  /^\@setfilename\s+([^.]+)/ and $fn = $1, next;
  /^\@settitle\s+([^.]+)/ and $tl = postprocess($1), next;
  
 +# Look for document encoding
 +/^\@documentencoding\s+([^.]+)/ and do {
 +$encoding = $1 unless defined $encoding;
 +next;
 +};
 +
  # Identify a man title but keep only the one we are interested in.
  /^\@c\s+man\s+title\s+([A-Za-z0-9-]+)\s+(.+)/ and do {
   if (exists $defs{$1}) {
 @@ -336,6 +343,8 @@ $inf = pop @instack;
  
  die No filename or title\n unless defined $fn  defined $tl;
  
 +print =encoding $encoding\n\n if defined $encoding;
 +
  $sects{NAME} = $fn \- $tl\n;
  $sects{FOOTNOTES} .= =back\n if exists $sects{FOOTNOTES};

Re: [Qemu-devel] [PATCH 2/2] Run pod2man with --utf8 option to enable utf8 in manpages

2012-03-11 Thread Michael Tokarev

Ping?  It's been more than a month since this patch has been posted.

Maybe it is a good candidate for -trivial queue?

Thanks,

/mjt

On 02.02.2012 18:16, Michael Tokarev wrote:
 This option makes no difference for manpages which contains only
 ascii chars.  But for manpages with actual UTF8 characters (qemu
 docs contains these), this change allows to see real characters
 instead of mojibakes or substitutes.
 
 Signed-off-By: Michael Tokarev m...@tls.msk.ru
 ---
  Makefile |9 +
  1 files changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/Makefile b/Makefile
 index 2560b59..737cda2 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -337,28 +337,29 @@ QMP/qmp-commands.txt: $(SRC_PATH)/qmp-commands.hx
  qemu-img-cmds.texi: $(SRC_PATH)/qemu-img-cmds.hx
   $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -t  $  $@,  GEN  
  $@)
  
 +POD2MAN = pod2man --utf8
  qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi
   $(call quiet-command, \
 perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $ qemu.pod  \
 -   pod2man --section=1 --center=  --release=  qemu.pod  $@, \
 +   $(POD2MAN) --section=1 --center=  --release=  qemu.pod  $@, \
   GEN   $@)
  
  qemu-img.1: qemu-img.texi qemu-img-cmds.texi
   $(call quiet-command, \
 perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $ qemu-img.pod  \
 -   pod2man --section=1 --center=  --release=  qemu-img.pod  $@, \
 +   $(POD2MAN) --section=1 --center=  --release=  qemu-img.pod  $@, \
   GEN   $@)
  
  fsdev/virtfs-proxy-helper.1: fsdev/virtfs-proxy-helper.texi
   $(call quiet-command, \
 perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $ 
 fsdev/virtfs-proxy-helper.pod  \
 -   pod2man --section=1 --center=  --release=  
 fsdev/virtfs-proxy-helper.pod  $@, \
 +   $(POD2MAN) --section=1 --center=  --release=  
 fsdev/virtfs-proxy-helper.pod  $@, \
   GEN   $@)
  
  qemu-nbd.8: qemu-nbd.texi
   $(call quiet-command, \
 perl -Ww -- $(SRC_PATH)/scripts/texi2pod.pl $ qemu-nbd.pod  \
 -   pod2man --section=8 --center=  --release=  qemu-nbd.pod  $@, \
 +   $(POD2MAN) --section=8 --center=  --release=  qemu-nbd.pod  $@, \
   GEN   $@)
  
  dvi: qemu-doc.dvi qemu-tech.dvi

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

2012-03-11 Thread Doug Goldstein

On Sat, Mar 10, 2012 at 12:24 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 03/10/2012 09:58 AM, Eduardo Habkost wrote:

On Sat, Mar 10, 2012 at 12:42:46PM +, Daniel P. Berrange wrote:

I could have sworn we had this discussion a year ago or so, and had
decided
that the default CPU models would be in something like
/usr/share/qemu/cpu-x86_64.conf
and loaded regardless of the -nodefconfig setting.
/etc/qemu/target-x86_64.conf
would be solely for end user configuration changes, not for QEMU builtin
defaults.

But looking at the code in QEMU, it doesn't seem we ever implemented
this ?

Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs
but,
contrary to our normal RHEL development practice, it was not based on
a cherry-pick of an upstream patch :-(

For sake of reference, I'm attaching the two patches from the RHEL6
source
RPM that do what I'm describing

NB, I'm not neccessarily advocating these patches for upstream. I still
maintain that libvirt should write out a config file containing the
exact CPU model description it desires and specify that with -readconfig.
The end result would be identical from QEMU's POV and it would avoid
playing games with QEMU's config loading code.

I agree that libvirt should just write the config somewhere. The problem
here is to define: 1) what information should be mandatory on that
config data; 2) who should be responsible to test and maintain sane
defaults (and where should they be maintained).

The current cpudef definitions are simply too low-level to require it to
be written from scratch. Lots of testing have to be done to make sure we
have working combinations of CPUID bits defined, so they can be used as
defaults or templates. Not facilitating reuse of those tested
defauls/templates by libvirt is duplication of efforts.

Really, if we expect libvirt to define all the CPU bits from scratch on
a config file, we could as well just expect libvirt to open /dev/kvm
itself and call the all CPUID setup ioctl()s itself. That's how
low-level some of the cpudef bits are.

Let's step back here.

Why are you writing these patches? It's probably not because you have a
desire to say -cpu Westmere when you run QEMU on your laptop. I'd wager to
say that no human has ever done that or that if they had, they did so by
accident because they read documentation and thought they had to.

Humans probably do one of two things: 1) no cpu option or 2) -cpu host.

So then why are you introducing -cpu Westmere? Because ovirt-engine has a
concept of datacenters and the entire datacenter has to use a compatible CPU
model to allow migration compatibility. Today, the interface that
ovirt-engine exposes is based on CPU codenames. Presumably ovirt-engine
wants to add a Westmere CPU group and as such have levied a requirement down
the stack to QEMU.

But there's no intrinsic reason why it uses CPU model names. VMware doesn't
do this. It has a concept of compatibility groups[1].

oVirt could just as well define compatibility groups like GroupA, GroupB,
GroupC, etc. and then the -cpu option we would be discussing would be -cpu
GroupA.

This is why it's a configuration option and not builtin to QEMU. It's a
user interface as as such, should be defined at a higher level.

Perhaps it really should be VDSM that is providing the model info to
libvirt? Then they can add whatever groups then want whenever they want as
long as we have the appropriate feature bits.

P.S. I spent 30 minutes the other day helping a user who was attempting to
figure out whether his processor was a Conroe, Penryn, etc. Making this
determination is fairly difficult and it makes me wonder whether having CPU
code names is even the best interface for oVirt..

[1]
http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1991

Regards,

Anthony Liguori

FWIW, as a user this would be a good improvement. As it stands right
now when a cluster of machines is established as being redundant
migratable machines for each other I must do the following for each
machine:
virsh -c qemu://machine/system capabilities | xpath
/capabilities/host/cpu machine-cpu.xml
Once I have that data I combine them together and use virsh
cpu-baseline, which is a handy addition from the past of doing it
manually, but still not optimal. This gives me a model which is mostly
meaningless and uninteresting to me, but I know all the guests must
use Penryn for example. If ovirt and by extension libvirt let me know
that guest X is running on CPU-A, I know I could migrate it to any
other machine supporting CPU-A or CPU-B (assuming B is a super set of
A).

--
Doug Goldstein

Re: [Qemu-devel] Support for Nested Paging

2012-03-11 Thread Ankur Agrawal

Hi,

Thanks for your reply.

I am a graduate student at Stony Brook University and am working on design
and implementation of hypervisors for OSCAR lab (
http://oscar.cs.stonybrook.edu/). Currently I am working on implementing
emulation of Nested Page Tables in QEMU as present in AMD-V architectures.

I would like to know if the QEMU team will be interested in having a patch
which emulates the Nested Page Table and other hardware virtualization
techniques supported by AMD-V or Intel-VT atchitectures.

I would  love to help in maintenance of my patch or any other issues in the
QEMU in future as well.

I would also like to know if there is any chance that this can become a
part of Google Summer of Code 2012.

Thanks,
Ankur

2012/3/3 陳韋任 che...@iis.sinica.edu.tw

  Does QEMU emulate the Nested Page Tables implemented by AMD-V
 architecture or the Intel VT?

  I think the answer is no.

  Also I am trying to understand the QEMU source with an objective of
 participating in the Google Summer of Code and contributing to QEMU. I have
 tried tracing through the code but seems this link
 http://repo.or.cz/w/qemu/stefanha.git/blob_plain/refs/heads/tracing:/docs/tracing.txtis
  not updated because many of the options do not work here. I would very
 happy if someone could provide me links to a good starting point to
 understand QEMU source code.

  The tracing you mentioned is not tend to help reading the code. Depends
 on
 which part of QEMU you're trying to play with, you have some background
 knowledge of it. See Getting to know the code on the QEMU wiki [1]. And
 the
 slides mentioned on the mail below is a good start.

  http://www.mail-archive.com/qemu-devel@nongnu.org/msg99864.html

 HTH,
 chenwj

 [1]
 http://wiki.qemu.org/Documentation/GettingStartedDevelopers#Getting_to_know_the_code

 --
 Wei-Ren Chen (陳韋任)
 Computer Systems Lab, Institute of Information Science,
 Academia Sinica, Taiwan (R.O.C.)
 Tel:886-2-2788-3799 #1667
 Homepage: http://people.cs.nctu.edu.tw/~chenwj

86 matches

Mail list logo