Re: [Qemu-devel] [PATCH REBASE/RESEND 0/4] Auto-document qdev devices

[Markus Armbruster]

Anthony Liguori anth...@codemonkey.ws writes:

 On 02/04/2011 12:18 AM, Amit Shah wrote:
 Hello,

 This is yet another rebase of the patchset I'd sent earlier.

 The usual notes apply: this is just the start, just getting the
 framework in place and a few examples so that people can then pick up
 and start documenting their devices and options.  We want to see all
 of the devices covered, and hopefully turn on build_bug_on() on an
 empty doc string.

 Maintainers should perhaps also look for patches that introduce
 options without documentation.

 That's the long-term goal (0.15-final).  For short-term, I'll be
 preparing follow-on patches that add doc strings for a few more
 options and perhaps bug people based on git history as to what
 documentation is to be added for some options.  Also to incorporate
 Markus's comments on beautifying output.

 The earlier this patchset goes in the better since it'll reduce
 conflicts and rebases needed.

 If this looks acceptable, please apply!


 I think we need to approach this in such a way that we generate not
 only inline documentation but out of line documentation.

 We need a way to extract the docs into a file.  That could mean having
 something like a .hx file or just doing some clever things with grep
 DEFINE_PROP.

Or stupid things with linking docs into a simple program that prints
them.

Anyway, let's not overengineer now.  This patch is a step forward: the
user gets help where there was none before.  It doesn't prejudice
further steps forward, such as putting the help information to
additional uses.

Re: [Qemu-devel] [PATCH REBASE/RESEND 1/4] qdev: Add a description field for qdev properties for documentation

[Markus Armbruster]

Anthony Liguori anth...@codemonkey.ws writes:

 On 02/17/2011 07:06 AM, Amit Shah wrote:
 On (Tue) 15 Feb 2011 [10:43:42], Anthony Liguori wrote:


   #define DEFINE_BLOCK_PROPERTIES(_state, _conf)  \
 -DEFINE_PROP_DRIVE(drive, _state, _conf.bs),   \
 +DEFINE_PROP_DRIVE(drive, _state, _conf.bs, ),   \
   DEFINE_PROP_UINT16(logical_block_size, _state,\
 -   _conf.logical_block_size, 512),  \
 +   _conf.logical_block_size, 512, ),  \
   DEFINE_PROP_UINT16(physical_block_size, _state,   \
 -   _conf.physical_block_size, 512), \
 -DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0),  \
 -DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0),\
 -DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1),\
 +   _conf.physical_block_size, 512, ), \
 +DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0, ), \
 +DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0, ), \
 +DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1, ), \
   DEFINE_PROP_UINT32(discard_granularity, _state, \
 -   _conf.discard_granularity, 0)
 +   _conf.discard_granularity, 0, )

 This is pretty horribly ugly.  If we were going this, we should at
 least introduce new defines that include a documentation field and
 not just add empty documentation fields.
  
 We've discussed this in the past.  Once this patch series gets in,
 I'll work to fill in the documentation here along with the
 maintainers.


 It means you're touching everything twice instead of touching
 everything once.  That's unnecessary churn and blame breakage.

 It's still just as greppable if you use a new name.

What names would you suggest?  DEFINE_PROP_FOO_WITH_DOCS()?  For all
fifteen FOOs?  Not a good idea, because the longer name makes doing
the right thing even less attractive.  We better encourage doing the
right thing.

Re: [Qemu-devel] [PATCH REBASE/RESEND 1/4] qdev: Add a description field for qdev properties for documentation

[Markus Armbruster]

Anthony Liguori anth...@codemonkey.ws writes:

 On 02/04/2011 12:18 AM, Amit Shah wrote:
 Add a 'description' along with each qdev property to document the input
 each qdev property takes.

 Signed-off-by: Amit Shahamit.s...@redhat.com
 Acked-by: Markus Armbrusterarm...@redhat.com
 ---
[...]
 diff --git a/block_int.h b/block_int.h
 index 6ebdc3e..fdde005 100644
 --- a/block_int.h
 +++ b/block_int.h
 @@ -250,15 +250,15 @@ static inline unsigned int 
 get_physical_block_exp(BlockConf *conf)
   }

   #define DEFINE_BLOCK_PROPERTIES(_state, _conf)  \
 -DEFINE_PROP_DRIVE(drive, _state, _conf.bs),   \
 +DEFINE_PROP_DRIVE(drive, _state, _conf.bs, ),   \
   DEFINE_PROP_UINT16(logical_block_size, _state,\
 -   _conf.logical_block_size, 512),  \
 +   _conf.logical_block_size, 512, ),  \
   DEFINE_PROP_UINT16(physical_block_size, _state,   \
 -   _conf.physical_block_size, 512), \
 -DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0),  \
 -DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0),\
 -DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1),\
 +   _conf.physical_block_size, 512, ), \
 +DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0, ), \
 +DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0, ), \
 +DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1, ), \
   DEFINE_PROP_UINT32(discard_granularity, _state, \
 -   _conf.discard_granularity, 0)
 +   _conf.discard_granularity, 0, )


 This is pretty horribly ugly.  If we were going this, we should at
 least introduce new defines that include a documentation field and not
 just add empty documentation fields.

In my opinion, making missing documentation look horribly ugly is a very
desirable feature ;)

Strategic decision: COW format (was: [Qemu-devel] Re: Comparing New Image Formats: FVD vs. QED)

[Markus Armbruster]

Kevin Wolf kw...@redhat.com writes:

 Am 15.02.2011 20:45, schrieb Chunqiang Tang:
 Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
 As you requested, I set up a wiki page for FVD at 
 http://wiki.qemu.org/Features/FVD
 . It includes a summary of FVD, a detailed specification of FVD, and a 
 comparison of the design and performance of FVD and QED. 
 
 See the figure at http://wiki.qemu.org/Features/FVD/Compare . This 
 figure 
 shows that the file creation throughput of NetApp's PostMark benchmark 
 under 
 FVD is 74.9% to 215% higher than that under QED.
 
 Hi Anthony,
 
 Please let me know if more information is needed. I would appreciate your 
 feedback and advice on the best way to proceed with FVD. 

 Yet another file format with yet another implementation is definitely
 not what we need. We should probably take some of the ideas in FVD and
 consider them for qcow3.

Got an assumption there: that the one COW format we need must be qcow3,
i.e. an evolution of qcow2.  Needs to be justified.  If that discussion
has happened on the list already, I missed it.  If not, it's overdue,
and then we better start it right away.

The choice of COW format will have a significant impact over a long
term.  That makes it a strategic decision.  Such decisions should not be
made purely on short-term considerations.

What are our core requirements for The One COW Format?

What's merely nice to have?

How much of it do we want to have ready for prime time in 0.15?

[...]

[Qemu-devel] Re: Strategic decision: COW format

[Kevin Wolf]

Am 18.02.2011 10:12, schrieb Markus Armbruster:
 Kevin Wolf kw...@redhat.com writes:
 
 Am 15.02.2011 20:45, schrieb Chunqiang Tang:
 Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
 As you requested, I set up a wiki page for FVD at 
 http://wiki.qemu.org/Features/FVD
 . It includes a summary of FVD, a detailed specification of FVD, and a 
 comparison of the design and performance of FVD and QED. 

 See the figure at http://wiki.qemu.org/Features/FVD/Compare . This 
 figure 
 shows that the file creation throughput of NetApp's PostMark benchmark 
 under 
 FVD is 74.9% to 215% higher than that under QED.

 Hi Anthony,

 Please let me know if more information is needed. I would appreciate your 
 feedback and advice on the best way to proceed with FVD. 

 Yet another file format with yet another implementation is definitely
 not what we need. We should probably take some of the ideas in FVD and
 consider them for qcow3.
 
 Got an assumption there: that the one COW format we need must be qcow3,
 i.e. an evolution of qcow2.  Needs to be justified.  If that discussion
 has happened on the list already, I missed it.  If not, it's overdue,
 and then we better start it right away.

Right. I probably wasn't very clear about what I mean with qcow3 either,
so let me try to summarize my reasoning.


The first point is an assumption that you made, too: That we want to
have only one format. I hope it's easy to agree on this, duplication is
bad and every additional format creates new maintenance burden,
especially if we're taking it serious. Until now, there were exactly two
formats for which we managed to do this, raw and qcow2. raw is more or
less for free, so with the introduction of another format, we basically
double the supported block driver code overnight (while not doubling the
number of developers).

The consequence of having only one file format is that it must be able
to obsolete the existing ones, most notably qcow2. We can only neglect
qcow1 today because we can tell users to use qcow2. It supports
everything that qcow1 supports and more. We couldn't have done this if
qcow2 lacked features compared to qcow1.

So the one really essential requirement that I see is that we provide a
way forward for _all_ users by maintaining all of qcow2's features. This
is the only way of getting people to not stay with qcow2.


Of course, you could invent another format that implements the same
features, but I think just carefully extending qcow2 has some real
advantages.

The first is that conversion of existing images would be really easy.
Basically increment the version number in the header file and you're
done. Structures would be compatible. If you compare it to file systems,
I rarely ever change the file system on a non-empty partition. Even if I
wanted, it's usually just too painful. Except when I was able to use
tune2fs -j to make ext3 out of ext2, that was really easy. We can
provide the same for qcow2 to qcow3 conversion, but not with a
completely new format.

Also, while obsoleting a file format means that we need not put much
effort in its maintenance, we still need to keep the code around for
reading old images. With an extension of qcow2, it would be the same
code that is used for both versions.

Third, qcow2 already exists, is used in practice and we have put quite
some effort into QA. At least initially confidence would be higher than
in a completely new, yet untested format. Remember that with qcow3 I'm
not talking about rewriting everything, it's a careful evolution, mostly
with optional additions here and there.

Kevin

[Qemu-devel] [PATCH v2 06/15] Synchronize VCPU states before reset

[Jan Kiszka]

This is required to support keeping VCPU states across a system reset.
If we do not read the current state before the reset,
cpu_synchronize_all_post_reset may write back incorrect state
information.

The first user of this will be MCE MSR synchronization which currently
works around the missing cpu_synchronize_all_states.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 vl.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index b436952..7751843 100644
--- a/vl.c
+++ b/vl.c
@@ -1452,6 +1452,7 @@ static void main_loop(void)
 }
 if (qemu_reset_requested()) {
 pause_all_vcpus();
+cpu_synchronize_all_states();
 qemu_system_reset();
 resume_all_vcpus();
 }
-- 
1.7.1

[Qemu-devel] [PATCH v2 10/15] x86: Run qemu_inject_x86_mce on target VCPU

[Jan Kiszka]

We will use the current TCG-only MCE injection path for KVM as well, and
then this read-modify-write of the target VCPU state has to be performed
synchronously in the corresponding thread.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 target-i386/helper.c |   87 +
 1 files changed, 58 insertions(+), 29 deletions(-)

diff --git a/target-i386/helper.c b/target-i386/helper.c
index e3ef40c..a32960c 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1067,29 +1067,42 @@ static void breakpoint_handler(CPUState *env)
 prev_debug_excp_handler(env);
 }
 
-static void
-qemu_inject_x86_mce(Monitor *mon, CPUState *cenv, int bank, uint64_t status,
-uint64_t mcg_status, uint64_t addr, uint64_t misc,
-int flags)
+typedef struct MCEInjectionParams {
+Monitor *mon;
+CPUState *env;
+int bank;
+uint64_t status;
+uint64_t mcg_status;
+uint64_t addr;
+uint64_t misc;
+int flags;
+} MCEInjectionParams;
+
+static void do_inject_x86_mce(void *data)
 {
-uint64_t mcg_cap = cenv-mcg_cap;
-uint64_t *banks = cenv-mce_banks + 4 * bank;
+MCEInjectionParams *params = data;
+CPUState *cenv = params-env;
+uint64_t *banks = cenv-mce_banks + 4 * params-bank;
+
+cpu_synchronize_state(cenv);
 
 /*
  * If there is an MCE exception being processed, ignore this SRAO MCE
  * unless unconditional injection was requested.
  */
-if (!(flags  MCE_INJECT_UNCOND_AO)  !(status  MCI_STATUS_AR)
+if (!(params-flags  MCE_INJECT_UNCOND_AO)
+ !(params-status  MCI_STATUS_AR)
  (cenv-mcg_status  MCG_STATUS_MCIP)) {
 return;
 }
-if (status  MCI_STATUS_UC) {
+
+if (params-status  MCI_STATUS_UC) {
 /*
  * if MSR_MCG_CTL is not all 1s, the uncorrected error
  * reporting is disabled
  */
-if ((mcg_cap  MCG_CTL_P)  cenv-mcg_ctl != ~(uint64_t)0) {
-monitor_printf(mon,
+if ((cenv-mcg_cap  MCG_CTL_P)  cenv-mcg_ctl != ~(uint64_t)0) {
+monitor_printf(params-mon,
CPU %d: Uncorrected error reporting disabled\n,
cenv-cpu_index);
 return;
@@ -1100,35 +1113,39 @@ qemu_inject_x86_mce(Monitor *mon, CPUState *cenv, int 
bank, uint64_t status,
  * reporting is disabled for the bank
  */
 if (banks[0] != ~(uint64_t)0) {
-monitor_printf(mon, CPU %d: Uncorrected error reporting disabled 
-   for bank %d\n, cenv-cpu_index, bank);
+monitor_printf(params-mon,
+   CPU %d: Uncorrected error reporting disabled for
+bank %d\n,
+   cenv-cpu_index, params-bank);
 return;
 }
 
 if ((cenv-mcg_status  MCG_STATUS_MCIP) ||
 !(cenv-cr[4]  CR4_MCE_MASK)) {
-monitor_printf(mon, CPU %d: Previous MCE still in progress, 
-raising triple fault\n, cenv-cpu_index);
+monitor_printf(params-mon,
+   CPU %d: Previous MCE still in progress, raising
+triple fault\n,
+   cenv-cpu_index);
 qemu_log_mask(CPU_LOG_RESET, Triple fault\n);
 qemu_system_reset_request();
 return;
 }
 if (banks[1]  MCI_STATUS_VAL) {
-status |= MCI_STATUS_OVER;
+params-status |= MCI_STATUS_OVER;
 }
-banks[2] = addr;
-banks[3] = misc;
-cenv-mcg_status = mcg_status;
-banks[1] = status;
+banks[2] = params-addr;
+banks[3] = params-misc;
+cenv-mcg_status = params-mcg_status;
+banks[1] = params-status;
 cpu_interrupt(cenv, CPU_INTERRUPT_MCE);
 } else if (!(banks[1]  MCI_STATUS_VAL)
|| !(banks[1]  MCI_STATUS_UC)) {
 if (banks[1]  MCI_STATUS_VAL) {
-status |= MCI_STATUS_OVER;
+params-status |= MCI_STATUS_OVER;
 }
-banks[2] = addr;
-banks[3] = misc;
-banks[1] = status;
+banks[2] = params-addr;
+banks[3] = params-misc;
+banks[1] = params-status;
 } else {
 banks[1] |= MCI_STATUS_OVER;
 }
@@ -1138,6 +1155,16 @@ void cpu_x86_inject_mce(Monitor *mon, CPUState *cenv, 
int bank,
 uint64_t status, uint64_t mcg_status, uint64_t addr,
 uint64_t misc, int flags)
 {
+MCEInjectionParams params = {
+.mon = mon,
+.env = cenv,
+.bank = bank,
+.status = status,
+.mcg_status = mcg_status,
+.addr = addr,
+.misc = misc,
+.flags = flags,
+};
 unsigned bank_num = cenv-mcg_cap  0xff;
 CPUState *env;
 int flag = 0;
@@ -1167,17 +1194,19 @@ void cpu_x86_inject_mce(Monitor *mon, CPUState 

[Qemu-devel] [PATCH v2 13/15] kvm: x86: Fail kvm_arch_init_vcpu if MCE initialization fails

[Jan Kiszka]

There is no reason to continue if the kernel claims to support MCE but
then fails to process our request.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 target-i386/kvm.c |   30 +-
 1 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 486efb9..44e5504 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -437,20 +437,24 @@ int kvm_arch_init_vcpu(CPUState *env)
 int banks;
 int ret;
 
-if (kvm_get_mce_cap_supported(env-kvm_state, 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;
-ret = kvm_vcpu_ioctl(env, KVM_X86_SETUP_MCE, mcg_cap);
-if (ret  0) {
-fprintf(stderr, KVM_X86_SETUP_MCE: %s, strerror(-ret));
-} else {
-env-mcg_cap = mcg_cap;
-}
+ret = kvm_get_mce_cap_supported(env-kvm_state, mcg_cap, banks);
+if (ret  0) {
+fprintf(stderr, kvm_get_mce_cap_supported: %s, strerror(-ret));
+return ret;
 }
+
+if (banks  MCE_BANKS_DEF) {
+banks = MCE_BANKS_DEF;
+}
+mcg_cap = MCE_CAP_DEF;
+mcg_cap |= banks;
+ret = kvm_vcpu_ioctl(env, KVM_X86_SETUP_MCE, mcg_cap);
+if (ret  0) {
+fprintf(stderr, KVM_X86_SETUP_MCE: %s, strerror(-ret));
+return ret;
+}
+
+env-mcg_cap = mcg_cap;
 }
 #endif
 
-- 
1.7.1

[Qemu-devel] [PATCH v2 01/15] x86: Account for MCE in cpu_has_work

[Jan Kiszka]

MCEs can be injected asynchronously, so they can also terminate the halt
state.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 target-i386/exec.h |   15 ++-
 1 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/target-i386/exec.h b/target-i386/exec.h
index fc8945b..d050dd0 100644
--- a/target-i386/exec.h
+++ b/target-i386/exec.h
@@ -293,15 +293,12 @@ static inline void load_eflags(int eflags, int 
update_mask)
 
 static inline int cpu_has_work(CPUState *env)
 {
-int work;
-
-work = (env-interrupt_request  CPU_INTERRUPT_HARD) 
-   (env-eflags  IF_MASK);
-work |= env-interrupt_request  CPU_INTERRUPT_NMI;
-work |= env-interrupt_request  CPU_INTERRUPT_INIT;
-work |= env-interrupt_request  CPU_INTERRUPT_SIPI;
-
-return work;
+return ((env-interrupt_request  CPU_INTERRUPT_HARD) 
+(env-eflags  IF_MASK)) ||
+   (env-interrupt_request  (CPU_INTERRUPT_NMI |
+  CPU_INTERRUPT_INIT |
+  CPU_INTERRUPT_SIPI |
+  CPU_INTERRUPT_MCE));
 }
 
 static inline int cpu_halted(CPUState *env) {
-- 
1.7.1

[Qemu-devel] [PATCH v2 00/15] [uq/master] Patch queue, part IV (MCE edition)

[Jan Kiszka]

Round 2 of this part, primarily addressing review comments:
 - Reworked CPU_INTERRUPT_MCE - exection translation
   (now done in kvm_arch_process_async_events, indeed much cleaner)
 - Add missing cpu_synchronize_state on pending MCE events for
   !kvm_irqchip_in_kernel
 - Split up KVM MCE code switch from old to new style into two patches
   and dropped some unneeded variable renamings
 - Fixed Windows build (qemu_ram_remap is POSIX-only)

Thanks for the feedback so far.

CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Huang Ying ying.hu...@intel.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com

Huang Ying (2):
  Add qemu_ram_remap
  KVM, MCE, unpoison memory address across reboot

Jan Kiszka (13):
  x86: Account for MCE in cpu_has_work
  x86: Perform implicit mcg_status reset
  x86: Small cleanups of MCE helpers
  x86: Refine error reporting of MCE injection services
  x86: Optionally avoid injecting AO MCEs while others are pending
  Synchronize VCPU states before reset
  kvm: x86: Move MCE functions together
  kvm: Rename kvm_arch_process_irqchip_events to async_events
  kvm: x86: Inject pending MCE events on state writeback
  x86: Run qemu_inject_x86_mce on target VCPU
  kvm: x86: Consolidate TCG and KVM MCE injection code
  kvm: x86: Clean up kvm_setup_mce
  kvm: x86: Fail kvm_arch_init_vcpu if MCE initialization fails

 cpu-all.h |8 +-
 cpu-common.h  |1 +
 exec.c|   63 +++-
 kvm-all.c |2 +-
 kvm.h |2 +-
 monitor.c |   11 +-
 qemu-common.h |6 +-
 target-i386/cpu.h |   11 +-
 target-i386/exec.h|   15 +-
 target-i386/helper.c  |  185 +---
 target-i386/kvm.c |  463 -
 target-i386/kvm_x86.h |   25 ---
 target-ppc/kvm.c  |2 +-
 target-s390x/kvm.c|2 +-
 vl.c  |1 +
 15 files changed, 399 insertions(+), 398 deletions(-)
 delete mode 100644 target-i386/kvm_x86.h

[Qemu-devel] [PATCH v2 05/15] x86: Optionally avoid injecting AO MCEs while others are pending

[Jan Kiszka]

Allow to tell cpu_x86_inject_mce that it should ignore Action Optional
MCE events when the target VCPU is still processing another one. This
will be used by KVM soon.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 monitor.c|7 +--
 target-i386/cpu.h|5 -
 target-i386/helper.c |   26 +++---
 3 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/monitor.c b/monitor.c
index 662df7c..ae20927 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2709,12 +2709,15 @@ static void do_inject_mce(Monitor *mon, const QDict 
*qdict)
 uint64_t mcg_status = qdict_get_int(qdict, mcg_status);
 uint64_t addr = qdict_get_int(qdict, addr);
 uint64_t misc = qdict_get_int(qdict, misc);
-int broadcast = qdict_get_try_bool(qdict, broadcast, 0);
+int flags = MCE_INJECT_UNCOND_AO;
 
+if (qdict_get_try_bool(qdict, broadcast, 0)) {
+flags |= MCE_INJECT_BROADCAST;
+}
 for (cenv = first_cpu; cenv != NULL; cenv = cenv-next_cpu) {
 if (cenv-cpu_index == cpu_index) {
 cpu_x86_inject_mce(mon, cenv, bank, status, mcg_status, addr, misc,
-   broadcast);
+   flags);
 break;
 }
 }
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 486af1d..d0eae75 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -987,8 +987,11 @@ static inline void cpu_get_tb_cpu_state(CPUState *env, 
target_ulong *pc,
 void do_cpu_init(CPUState *env);
 void do_cpu_sipi(CPUState *env);
 
+#define MCE_INJECT_BROADCAST1
+#define MCE_INJECT_UNCOND_AO2
+
 void cpu_x86_inject_mce(Monitor *mon, CPUState *cenv, int bank,
 uint64_t status, uint64_t mcg_status, uint64_t addr,
-uint64_t misc, int broadcast);
+uint64_t misc, int flags);
 
 #endif /* CPU_I386_H */
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 462d332..e3ef40c 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1069,11 +1069,20 @@ static void breakpoint_handler(CPUState *env)
 
 static void
 qemu_inject_x86_mce(Monitor *mon, CPUState *cenv, int bank, uint64_t status,
-uint64_t mcg_status, uint64_t addr, uint64_t misc)
+uint64_t mcg_status, uint64_t addr, uint64_t misc,
+int flags)
 {
 uint64_t mcg_cap = cenv-mcg_cap;
 uint64_t *banks = cenv-mce_banks + 4 * bank;
 
+/*
+ * If there is an MCE exception being processed, ignore this SRAO MCE
+ * unless unconditional injection was requested.
+ */
+if (!(flags  MCE_INJECT_UNCOND_AO)  !(status  MCI_STATUS_AR)
+ (cenv-mcg_status  MCG_STATUS_MCIP)) {
+return;
+}
 if (status  MCI_STATUS_UC) {
 /*
  * if MSR_MCG_CTL is not all 1s, the uncorrected error
@@ -1127,7 +1136,7 @@ qemu_inject_x86_mce(Monitor *mon, CPUState *cenv, int 
bank, uint64_t status,
 
 void cpu_x86_inject_mce(Monitor *mon, CPUState *cenv, int bank,
 uint64_t status, uint64_t mcg_status, uint64_t addr,
-uint64_t misc, int broadcast)
+uint64_t misc, int flags)
 {
 unsigned bank_num = cenv-mcg_cap  0xff;
 CPUState *env;
@@ -1145,27 +1154,30 @@ void cpu_x86_inject_mce(Monitor *mon, CPUState *cenv, 
int bank,
 monitor_printf(mon, Invalid MCE status code\n);
 return;
 }
-if (broadcast  !cpu_x86_support_mca_broadcast(cenv)) {
+if ((flags  MCE_INJECT_BROADCAST)
+ !cpu_x86_support_mca_broadcast(cenv)) {
 monitor_printf(mon, Guest CPU does not support MCA broadcast\n);
 return;
 }
 
 if (kvm_enabled()) {
-if (broadcast) {
+if (flags  MCE_INJECT_BROADCAST) {
 flag |= MCE_BROADCAST;
 }
 
 kvm_inject_x86_mce(cenv, bank, status, mcg_status, addr, misc, flag);
 } else {
-qemu_inject_x86_mce(mon, cenv, bank, status, mcg_status, addr, misc);
-if (broadcast) {
+qemu_inject_x86_mce(mon, cenv, bank, status, mcg_status, addr, misc,
+flags);
+if (flags  MCE_INJECT_BROADCAST) {
 for (env = first_cpu; env != NULL; env = env-next_cpu) {
 if (cenv == env) {
 continue;
 }
 qemu_inject_x86_mce(mon, env, 1,
 MCI_STATUS_VAL | MCI_STATUS_UC,
-MCG_STATUS_MCIP | MCG_STATUS_RIPV, 0, 0);
+MCG_STATUS_MCIP | MCG_STATUS_RIPV, 0, 0,
+flags);
 }
 }
 }
-- 
1.7.1

[Qemu-devel] [PATCH v2 09/15] kvm: x86: Inject pending MCE events on state writeback

[Jan Kiszka]

The current way of injecting MCE events without updating of and
synchronizing with the CPUState is broken and causes spurious
corruptions of the MCE-related parts of the CPUState.

As a first step towards a fix, enhance the state writeback code with
support for injecting events that are pending in the CPUState. A pending
exception will then be signaled via cpu_interrupt(CPU_INTERRUPT_MCE).
And, just like for TCG, we need to leave the halt state when
CPU_INTERRUPT_MCE is pending (left broken for the to-be-removed old KVM
code).

This will also allow to unify TCG and KVM injection code.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 target-i386/kvm.c |   60 +
 1 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index a416554..939edc8 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -467,6 +467,38 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t 
status,
 #endif /* !KVM_CAP_MCE*/
 }
 
+static int kvm_inject_mce_oldstyle(CPUState *env)
+{
+#ifdef KVM_CAP_MCE
+if (!kvm_has_vcpu_events()  env-exception_injected == EXCP12_MCHK) {
+unsigned int bank, bank_num = env-mcg_cap  0xff;
+struct kvm_x86_mce mce;
+
+env-exception_injected = -1;
+
+/*
+ * There must be at least one bank in use if an MCE is pending.
+ * Find it and use its values for the event injection.
+ */
+for (bank = 0; bank  bank_num; bank++) {
+if (env-mce_banks[bank * 4 + 1]  MCI_STATUS_VAL) {
+break;
+}
+}
+assert(bank  bank_num);
+
+mce.bank = bank;
+mce.status = env-mce_banks[bank * 4 + 1];
+mce.mcg_status = env-mcg_status;
+mce.addr = env-mce_banks[bank * 4 + 2];
+mce.misc = env-mce_banks[bank * 4 + 3];
+
+return kvm_vcpu_ioctl(env, KVM_X86_SET_MCE, mce);
+}
+#endif /* KVM_CAP_MCE */
+return 0;
+}
+
 static void cpu_update_state(void *opaque, int running, int reason)
 {
 CPUState *env = opaque;
@@ -1539,6 +1571,11 @@ int kvm_arch_put_registers(CPUState *env, int level)
 if (ret  0) {
 return ret;
 }
+/* must be before kvm_put_msrs */
+ret = kvm_inject_mce_oldstyle(env);
+if (ret  0) {
+return ret;
+}
 ret = kvm_put_msrs(env, level);
 if (ret  0) {
 return ret;
@@ -1677,6 +1714,29 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run 
*run)
 
 int kvm_arch_process_async_events(CPUState *env)
 {
+if (env-interrupt_request  CPU_INTERRUPT_MCE) {
+/* We must not raise CPU_INTERRUPT_MCE if it's not supported. */
+assert(env-mcg_cap);
+
+env-interrupt_request = ~CPU_INTERRUPT_MCE;
+
+kvm_cpu_synchronize_state(env);
+
+if (env-exception_injected == EXCP08_DBLE) {
+/* this means triple fault */
+qemu_system_reset_request();
+env-exit_request = 1;
+return 0;
+}
+env-exception_injected = EXCP12_MCHK;
+env-has_error_code = 0;
+
+env-halted = 0;
+if (kvm_irqchip_in_kernel()  env-mp_state == KVM_MP_STATE_HALTED) {
+env-mp_state = KVM_MP_STATE_RUNNABLE;
+}
+}
+
 if (kvm_irqchip_in_kernel()) {
 return 0;
 }
-- 
1.7.1

[Qemu-devel] [PATCH v2 12/15] kvm: x86: Clean up kvm_setup_mce

[Jan Kiszka]

There is nothing to abstract here. Fold kvm_setup_mce into its caller
and fix up the error reporting (return code of kvm_vcpu_ioctl holds the
error value).

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 target-i386/kvm.c |   11 ---
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index be896dd..486efb9 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -187,11 +187,6 @@ static int kvm_get_mce_cap_supported(KVMState *s, uint64_t 
*mce_cap,
 return -ENOSYS;
 }
 
-static int kvm_setup_mce(CPUState *env, uint64_t *mcg_cap)
-{
-return kvm_vcpu_ioctl(env, KVM_X86_SETUP_MCE, mcg_cap);
-}
-
 static void kvm_mce_inject(CPUState *env, target_phys_addr_t paddr, int code)
 {
 uint64_t status = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN |
@@ -440,6 +435,7 @@ int kvm_arch_init_vcpu(CPUState *env)
  kvm_check_extension(env-kvm_state, KVM_CAP_MCE)  0) {
 uint64_t mcg_cap;
 int banks;
+int ret;
 
 if (kvm_get_mce_cap_supported(env-kvm_state, mcg_cap, banks)) {
 perror(kvm_get_mce_cap_supported FAILED);
@@ -448,8 +444,9 @@ int kvm_arch_init_vcpu(CPUState *env)
 banks = MCE_BANKS_DEF;
 mcg_cap = MCE_CAP_DEF;
 mcg_cap |= banks;
-if (kvm_setup_mce(env, mcg_cap)) {
-perror(kvm_setup_mce FAILED);
+ret = kvm_vcpu_ioctl(env, KVM_X86_SETUP_MCE, mcg_cap);
+if (ret  0) {
+fprintf(stderr, KVM_X86_SETUP_MCE: %s, strerror(-ret));
 } else {
 env-mcg_cap = mcg_cap;
 }
-- 
1.7.1

[Qemu-devel] MIPS dynamically linked ELF with Qemu

[maheen butt]

hi 
I want to run MIPS dynamically linked ELF in user mode emulation on x86 host 
machine, what should I do?



  

[Qemu-devel] [PATCH v2 04/15] x86: Refine error reporting of MCE injection services

[Jan Kiszka]

As this service is used by the human monitor, make sure that errors get
reported to the right channel, and also raise the verbosity.

This requires to move Monitor typedef in qemu-common.h to resolve the
include dependency.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 monitor.c|4 +-
 qemu-common.h|6 ++--
 target-i386/cpu.h|6 ++--
 target-i386/helper.c |   79 +-
 4 files changed, 54 insertions(+), 41 deletions(-)

diff --git a/monitor.c b/monitor.c
index 45b0cc2..662df7c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2712,8 +2712,8 @@ static void do_inject_mce(Monitor *mon, const QDict 
*qdict)
 int broadcast = qdict_get_try_bool(qdict, broadcast, 0);
 
 for (cenv = first_cpu; cenv != NULL; cenv = cenv-next_cpu) {
-if (cenv-cpu_index == cpu_index  cenv-mcg_cap) {
-cpu_x86_inject_mce(cenv, bank, status, mcg_status, addr, misc,
+if (cenv-cpu_index == cpu_index) {
+cpu_x86_inject_mce(mon, cenv, bank, status, mcg_status, addr, misc,
broadcast);
 break;
 }
diff --git a/qemu-common.h b/qemu-common.h
index a4d9c21..6ac29cc 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -18,6 +18,9 @@ typedef struct QEMUFile QEMUFile;
 typedef struct QEMUBH QEMUBH;
 typedef struct DeviceState DeviceState;
 
+struct Monitor;
+typedef struct Monitor Monitor;
+
 /* we put basic includes here to avoid repeating them in device drivers */
 #include stdlib.h
 #include stdio.h
@@ -324,9 +327,6 @@ void qemu_iovec_to_buffer(QEMUIOVector *qiov, void *buf);
 void qemu_iovec_from_buffer(QEMUIOVector *qiov, const void *buf, size_t count);
 void qemu_iovec_memset(QEMUIOVector *qiov, int c, size_t count);
 
-struct Monitor;
-typedef struct Monitor Monitor;
-
 /* Convert a byte between binary and BCD.  */
 static inline uint8_t to_bcd(uint8_t val)
 {
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 52bb48e..486af1d 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -987,8 +987,8 @@ static inline void cpu_get_tb_cpu_state(CPUState *env, 
target_ulong *pc,
 void do_cpu_init(CPUState *env);
 void do_cpu_sipi(CPUState *env);
 
-void cpu_x86_inject_mce(CPUState *cenv, int bank, uint64_t status,
-uint64_t mcg_status, uint64_t addr, uint64_t misc,
-int broadcast);
+void cpu_x86_inject_mce(Monitor *mon, CPUState *cenv, int bank,
+uint64_t status, uint64_t mcg_status, uint64_t addr,
+uint64_t misc, int broadcast);
 
 #endif /* CPU_I386_H */
diff --git a/target-i386/helper.c b/target-i386/helper.c
index ba3bed9..462d332 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -30,6 +30,7 @@
 #include kvm_x86.h
 #ifndef CONFIG_USER_ONLY
 #include sysemu.h
+#include monitor.h
 #endif
 
 //#define DEBUG_MMU
@@ -1067,33 +1068,38 @@ static void breakpoint_handler(CPUState *env)
 }
 
 static void
-qemu_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
+qemu_inject_x86_mce(Monitor *mon, CPUState *cenv, int bank, uint64_t status,
 uint64_t mcg_status, uint64_t addr, uint64_t misc)
 {
 uint64_t mcg_cap = cenv-mcg_cap;
-uint64_t *banks = cenv-mce_banks;
-
-/*
- * if MSR_MCG_CTL is not all 1s, the uncorrected error
- * reporting is disabled
- */
-if ((status  MCI_STATUS_UC)  (mcg_cap  MCG_CTL_P) 
-cenv-mcg_ctl != ~(uint64_t)0) {
-return;
-}
-banks += 4 * bank;
-/*
- * if MSR_MCi_CTL is not all 1s, the uncorrected error
- * reporting is disabled for the bank
- */
-if ((status  MCI_STATUS_UC)  banks[0] != ~(uint64_t)0) {
-return;
-}
+uint64_t *banks = cenv-mce_banks + 4 * bank;
+
 if (status  MCI_STATUS_UC) {
+/*
+ * if MSR_MCG_CTL is not all 1s, the uncorrected error
+ * reporting is disabled
+ */
+if ((mcg_cap  MCG_CTL_P)  cenv-mcg_ctl != ~(uint64_t)0) {
+monitor_printf(mon,
+   CPU %d: Uncorrected error reporting disabled\n,
+   cenv-cpu_index);
+return;
+}
+
+/*
+ * if MSR_MCi_CTL is not all 1s, the uncorrected error
+ * reporting is disabled for the bank
+ */
+if (banks[0] != ~(uint64_t)0) {
+monitor_printf(mon, CPU %d: Uncorrected error reporting disabled 
+   for bank %d\n, cenv-cpu_index, bank);
+return;
+}
+
 if ((cenv-mcg_status  MCG_STATUS_MCIP) ||
 !(cenv-cr[4]  CR4_MCE_MASK)) {
-fprintf(stderr, injects mce exception while previous 
-one is in progress!\n);
+monitor_printf(mon, CPU %d: Previous MCE still in progress, 
+   

[Qemu-devel] [PATCH v2 14/15] Add qemu_ram_remap

[Jan Kiszka]

From: Huang Ying ying.hu...@intel.com

qemu_ram_remap() unmaps the specified RAM pages, then re-maps these
pages again.  This is used by KVM HWPoison support to clear HWPoisoned
page tables across guest rebooting, so that a new page may be
allocated later to recover the memory error.

[ Jan: style fixlets, WIN32 fix ]

Signed-off-by: Huang Ying ying.hu...@intel.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 cpu-all.h|4 +++
 cpu-common.h |1 +
 exec.c   |   63 +-
 3 files changed, 67 insertions(+), 1 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index caf5e6c..4f4631d 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -863,10 +863,14 @@ target_phys_addr_t cpu_get_phys_page_debug(CPUState *env, 
target_ulong addr);
 extern int phys_ram_fd;
 extern ram_addr_t ram_size;
 
+/* RAM is pre-allocated and passed into qemu_ram_alloc_from_ptr */
+#define RAM_PREALLOC_MASK   (1  0)
+
 typedef struct RAMBlock {
 uint8_t *host;
 ram_addr_t offset;
 ram_addr_t length;
+uint32_t flags;
 char idstr[256];
 QLIST_ENTRY(RAMBlock) next;
 #if defined(__linux__)  !defined(TARGET_S390X)
diff --git a/cpu-common.h b/cpu-common.h
index 54d21d4..ef4e8da 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -50,6 +50,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, const 
char *name,
 ram_addr_t size, void *host);
 ram_addr_t qemu_ram_alloc(DeviceState *dev, const char *name, ram_addr_t size);
 void qemu_ram_free(ram_addr_t addr);
+void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
 /* This should only be used for ram local to a device.  */
 void *qemu_get_ram_ptr(ram_addr_t addr);
 /* Same but slower, to use for migration, where the order of
diff --git a/exec.c b/exec.c
index d611100..9308a97 100644
--- a/exec.c
+++ b/exec.c
@@ -2867,6 +2867,7 @@ ram_addr_t qemu_ram_alloc_from_ptr(DeviceState *dev, 
const char *name,
 
 if (host) {
 new_block-host = host;
+new_block-flags |= RAM_PREALLOC_MASK;
 } else {
 if (mem_path) {
 #if defined (__linux__)  !defined(TARGET_S390X)
@@ -2920,7 +2921,9 @@ void qemu_ram_free(ram_addr_t addr)
 QLIST_FOREACH(block, ram_list.blocks, next) {
 if (addr == block-offset) {
 QLIST_REMOVE(block, next);
-if (mem_path) {
+if (block-flags  RAM_PREALLOC_MASK) {
+;
+} else if (mem_path) {
 #if defined (__linux__)  !defined(TARGET_S390X)
 if (block-fd) {
 munmap(block-host, block-length);
@@ -2943,6 +2946,64 @@ void qemu_ram_free(ram_addr_t addr)
 
 }
 
+#ifndef _WIN32
+void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
+{
+RAMBlock *block;
+ram_addr_t offset;
+int flags;
+void *area, *vaddr;
+
+QLIST_FOREACH(block, ram_list.blocks, next) {
+offset = addr - block-offset;
+if (offset  block-length) {
+vaddr = block-host + offset;
+if (block-flags  RAM_PREALLOC_MASK) {
+;
+} else {
+flags = MAP_FIXED;
+munmap(vaddr, length);
+if (mem_path) {
+#if defined(__linux__)  !defined(TARGET_S390X)
+if (block-fd) {
+#ifdef MAP_POPULATE
+flags |= mem_prealloc ? MAP_POPULATE | MAP_SHARED :
+MAP_PRIVATE;
+#else
+flags |= MAP_PRIVATE;
+#endif
+area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
+flags, block-fd, offset);
+} else {
+flags |= MAP_PRIVATE | MAP_ANONYMOUS;
+area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
+flags, -1, 0);
+}
+#endif
+} else {
+#if defined(TARGET_S390X)  defined(CONFIG_KVM)
+flags |= MAP_SHARED | MAP_ANONYMOUS;
+area = mmap(vaddr, length, PROT_EXEC|PROT_READ|PROT_WRITE,
+flags, -1, 0);
+#else
+flags |= MAP_PRIVATE | MAP_ANONYMOUS;
+area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
+flags, -1, 0);
+#endif
+}
+if (area != vaddr) {
+fprintf(stderr, Could not remap addr: %lx@%lx\n,
+length, addr);
+exit(1);
+}
+qemu_madvise(vaddr, length, QEMU_MADV_MERGEABLE);
+}
+return;
+}
+}
+}
+#endif /* !_WIN32 */
+
 /* Return a host pointer to ram allocated with qemu_ram_alloc.
With the exception of the softmmu code in this file, this should
only be used for local memory (e.g. video ram) that the device owns,
-- 
1.7.1

[Qemu-devel] [PATCH v2 15/15] KVM, MCE, unpoison memory address across reboot

[Jan Kiszka]

From: Huang Ying ying.hu...@intel.com

In Linux kernel HWPoison processing implementation, the virtual
address in processes mapping the error physical memory page is marked
as HWPoison.  So that, the further accessing to the virtual
address will kill corresponding processes with SIGBUS.

If the error physical memory page is used by a KVM guest, the SIGBUS
will be sent to QEMU, and QEMU will simulate a MCE to report that
memory error to the guest OS.  If the guest OS can not recover from
the error (for example, the page is accessed by kernel code), guest OS
will reboot the system.  But because the underlying host virtual
address backing the guest physical memory is still poisoned, if the
guest system accesses the corresponding guest physical memory even
after rebooting, the SIGBUS will still be sent to QEMU and MCE will be
simulated.  That is, guest system can not recover via rebooting.

In fact, across rebooting, the contents of guest physical memory page
need not to be kept.  We can allocate a new host physical page to
back the corresponding guest physical address.

This patch fixes this issue in QEMU-KVM via calling qemu_ram_remap()
to clear the corresponding page table entry, so that make it possible
to allocate a new page to recover the issue.

[ Jan: rebasing and tiny cleanups]

Signed-off-by: Huang Ying ying.hu...@intel.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 target-i386/kvm.c |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 44e5504..7b7105d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -173,7 +173,40 @@ static int get_para_features(CPUState *env)
 }
 #endif /* CONFIG_KVM_PARA */
 
+typedef struct HWPoisonPage {
+ram_addr_t ram_addr;
+QLIST_ENTRY(HWPoisonPage) list;
+} HWPoisonPage;
+
+static QLIST_HEAD(, HWPoisonPage) hwpoison_page_list =
+QLIST_HEAD_INITIALIZER(hwpoison_page_list);
+
+static void kvm_unpoison_all(void *param)
+{
+HWPoisonPage *page, *next_page;
+
+QLIST_FOREACH_SAFE(page, hwpoison_page_list, list, next_page) {
+QLIST_REMOVE(page, list);
+qemu_ram_remap(page-ram_addr, TARGET_PAGE_SIZE);
+qemu_free(page);
+}
+}
+
 #ifdef KVM_CAP_MCE
+static void kvm_hwpoison_page_add(ram_addr_t ram_addr)
+{
+HWPoisonPage *page;
+
+QLIST_FOREACH(page, hwpoison_page_list, list) {
+if (page-ram_addr == ram_addr) {
+return;
+}
+}
+page = qemu_malloc(sizeof(HWPoisonPage));
+page-ram_addr = ram_addr;
+QLIST_INSERT_HEAD(hwpoison_page_list, page, list);
+}
+
 static int kvm_get_mce_cap_supported(KVMState *s, uint64_t *mce_cap,
  int *max_banks)
 {
@@ -233,6 +266,7 @@ int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void 
*addr)
 hardware_memory_error();
 }
 }
+kvm_hwpoison_page_add(ram_addr);
 kvm_mce_inject(env, paddr, code);
 } else
 #endif /* KVM_CAP_MCE */
@@ -263,6 +297,7 @@ int kvm_arch_on_sigbus(int code, void *addr)
 QEMU itself instead of guest system!: %p\n, addr);
 return 0;
 }
+kvm_hwpoison_page_add(ram_addr);
 kvm_mce_inject(first_cpu, paddr, code);
 } else
 #endif /* KVM_CAP_MCE */
@@ -571,6 +606,7 @@ int kvm_arch_init(KVMState *s)
 fprintf(stderr, e820_add_entry() table is full\n);
 return ret;
 }
+qemu_register_reset(kvm_unpoison_all, NULL);
 
 return 0;
 }
-- 
1.7.1

[Qemu-devel] [PATCH v2 08/15] kvm: Rename kvm_arch_process_irqchip_events to async_events

[Jan Kiszka]

We will broaden the scope of this function on x86 beyond irqchip events.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 kvm-all.c  |2 +-
 kvm.h  |2 +-
 target-i386/kvm.c  |2 +-
 target-ppc/kvm.c   |2 +-
 target-s390x/kvm.c |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index e6a7de4..6522a32 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -893,7 +893,7 @@ int kvm_cpu_exec(CPUState *env)
 
 DPRINTF(kvm_cpu_exec()\n);
 
-if (kvm_arch_process_irqchip_events(env)) {
+if (kvm_arch_process_async_events(env)) {
 env-exit_request = 0;
 return EXCP_HLT;
 }
diff --git a/kvm.h b/kvm.h
index 59b2c29..7bc04e0 100644
--- a/kvm.h
+++ b/kvm.h
@@ -102,7 +102,7 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run *run);
 
 int kvm_arch_handle_exit(CPUState *env, struct kvm_run *run);
 
-int kvm_arch_process_irqchip_events(CPUState *env);
+int kvm_arch_process_async_events(CPUState *env);
 
 int kvm_arch_get_registers(CPUState *env);
 
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index f909661..a416554 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1675,7 +1675,7 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
 cpu_set_apic_base(env-apic_state, run-apic_base);
 }
 
-int kvm_arch_process_irqchip_events(CPUState *env)
+int kvm_arch_process_async_events(CPUState *env)
 {
 if (kvm_irqchip_in_kernel()) {
 return 0;
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 3924f4b..6c99a16 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -259,7 +259,7 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
 {
 }
 
-int kvm_arch_process_irqchip_events(CPUState *env)
+int kvm_arch_process_async_events(CPUState *env)
 {
 return 0;
 }
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index b349812..5673a95 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -177,7 +177,7 @@ void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
 {
 }
 
-int kvm_arch_process_irqchip_events(CPUState *env)
+int kvm_arch_process_async_events(CPUState *env)
 {
 return 0;
 }
-- 
1.7.1

[Qemu-devel] [PATCH v2 03/15] x86: Small cleanups of MCE helpers

[Jan Kiszka]

Fix some code style issues, use proper headers, and align to cpu_x86
naming scheme. No functional changes.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 cpu-all.h|4 
 monitor.c|2 +-
 target-i386/cpu.h|5 +
 target-i386/helper.c |   41 -
 4 files changed, 30 insertions(+), 22 deletions(-)

diff --git a/cpu-all.h b/cpu-all.h
index 87b0f86..caf5e6c 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -971,8 +971,4 @@ void dump_exec_info(FILE *f, fprintf_function cpu_fprintf);
 int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
 uint8_t *buf, int len, int is_write);
 
-void cpu_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
-uint64_t mcg_status, uint64_t addr, uint64_t misc,
-int broadcast);
-
 #endif /* CPU_ALL_H */
diff --git a/monitor.c b/monitor.c
index 22ae3bb..45b0cc2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2713,7 +2713,7 @@ static void do_inject_mce(Monitor *mon, const QDict 
*qdict)
 
 for (cenv = first_cpu; cenv != NULL; cenv = cenv-next_cpu) {
 if (cenv-cpu_index == cpu_index  cenv-mcg_cap) {
-cpu_inject_x86_mce(cenv, bank, status, mcg_status, addr, misc,
+cpu_x86_inject_mce(cenv, bank, status, mcg_status, addr, misc,
broadcast);
 break;
 }
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 75156e7..52bb48e 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -986,4 +986,9 @@ static inline void cpu_get_tb_cpu_state(CPUState *env, 
target_ulong *pc,
 
 void do_cpu_init(CPUState *env);
 void do_cpu_sipi(CPUState *env);
+
+void cpu_x86_inject_mce(CPUState *cenv, int bank, uint64_t status,
+uint64_t mcg_status, uint64_t addr, uint64_t misc,
+int broadcast);
+
 #endif /* CPU_I386_H */
diff --git a/target-i386/helper.c b/target-i386/helper.c
index f41416f..ba3bed9 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -28,6 +28,9 @@
 #include qemu-common.h
 #include kvm.h
 #include kvm_x86.h
+#ifndef CONFIG_USER_ONLY
+#include sysemu.h
+#endif
 
 //#define DEBUG_MMU
 
@@ -1063,11 +1066,9 @@ static void breakpoint_handler(CPUState *env)
 prev_debug_excp_handler(env);
 }
 
-/* This should come from sysemu.h - if we could include it here... */
-void qemu_system_reset_request(void);
-
-static void qemu_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
-uint64_t mcg_status, uint64_t addr, uint64_t misc)
+static void
+qemu_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
+uint64_t mcg_status, uint64_t addr, uint64_t misc)
 {
 uint64_t mcg_cap = cenv-mcg_cap;
 uint64_t *banks = cenv-mce_banks;
@@ -1077,15 +1078,17 @@ static void qemu_inject_x86_mce(CPUState *cenv, int 
bank, uint64_t status,
  * reporting is disabled
  */
 if ((status  MCI_STATUS_UC)  (mcg_cap  MCG_CTL_P) 
-cenv-mcg_ctl != ~(uint64_t)0)
+cenv-mcg_ctl != ~(uint64_t)0) {
 return;
+}
 banks += 4 * bank;
 /*
  * if MSR_MCi_CTL is not all 1s, the uncorrected error
  * reporting is disabled for the bank
  */
-if ((status  MCI_STATUS_UC)  banks[0] != ~(uint64_t)0)
+if ((status  MCI_STATUS_UC)  banks[0] != ~(uint64_t)0) {
 return;
+}
 if (status  MCI_STATUS_UC) {
 if ((cenv-mcg_status  MCG_STATUS_MCIP) ||
 !(cenv-cr[4]  CR4_MCE_MASK)) {
@@ -1095,8 +1098,9 @@ static void qemu_inject_x86_mce(CPUState *cenv, int bank, 
uint64_t status,
 qemu_system_reset_request();
 return;
 }
-if (banks[1]  MCI_STATUS_VAL)
+if (banks[1]  MCI_STATUS_VAL) {
 status |= MCI_STATUS_OVER;
+}
 banks[2] = addr;
 banks[3] = misc;
 cenv-mcg_status = mcg_status;
@@ -1104,16 +1108,18 @@ static void qemu_inject_x86_mce(CPUState *cenv, int 
bank, uint64_t status,
 cpu_interrupt(cenv, CPU_INTERRUPT_MCE);
 } else if (!(banks[1]  MCI_STATUS_VAL)
|| !(banks[1]  MCI_STATUS_UC)) {
-if (banks[1]  MCI_STATUS_VAL)
+if (banks[1]  MCI_STATUS_VAL) {
 status |= MCI_STATUS_OVER;
+}
 banks[2] = addr;
 banks[3] = misc;
 banks[1] = status;
-} else
+} else {
 banks[1] |= MCI_STATUS_OVER;
+}
 }
 
-void cpu_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
+void cpu_x86_inject_mce(CPUState *cenv, int bank, uint64_t status,
 uint64_t mcg_status, uint64_t addr, uint64_t misc,
 int broadcast)
 {
@@ -1155,15 +1161,16 @@ void cpu_inject_x86_mce(CPUState *cenv, int bank, 
uint64_t status,
 
 static void mce_init(CPUX86State 

[Qemu-devel] [PATCH v2 07/15] kvm: x86: Move MCE functions together

[Jan Kiszka]

Pure function suffling to avoid multiple #ifdef KVM_CAP_MCE sections,
no functional changes. While at it, annotate some #ifdef sections.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 target-i386/kvm.c |  346 ++---
 1 files changed, 171 insertions(+), 175 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 0aa0a41..f909661 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -172,7 +172,7 @@ static int get_para_features(CPUState *env)
 #endif
 return features;
 }
-#endif
+#endif /* CONFIG_KVM_PARA */
 
 #ifdef KVM_CAP_MCE
 static int kvm_get_mce_cap_supported(KVMState *s, uint64_t *mce_cap,
@@ -273,8 +273,174 @@ static void kvm_inject_x86_mce_on(CPUState *env, struct 
kvm_x86_mce *mce,
 run_on_cpu(env, kvm_do_inject_x86_mce, data);
 }
 
-static void kvm_mce_broadcast_rest(CPUState *env);
-#endif
+static void kvm_mce_broadcast_rest(CPUState *env)
+{
+struct kvm_x86_mce mce = {
+.bank = 1,
+.status = MCI_STATUS_VAL | MCI_STATUS_UC,
+.mcg_status = MCG_STATUS_MCIP | MCG_STATUS_RIPV,
+.addr = 0,
+.misc = 0,
+};
+CPUState *cenv;
+
+/* Broadcast MCA signal for processor version 06H_EH and above */
+if (cpu_x86_support_mca_broadcast(env)) {
+for (cenv = first_cpu; cenv != NULL; cenv = cenv-next_cpu) {
+if (cenv == env) {
+continue;
+}
+kvm_inject_x86_mce_on(cenv, mce, ABORT_ON_ERROR);
+}
+}
+}
+
+static void kvm_mce_inj_srar_dataload(CPUState *env, target_phys_addr_t paddr)
+{
+struct kvm_x86_mce mce = {
+.bank = 9,
+.status = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN
+  | MCI_STATUS_MISCV | MCI_STATUS_ADDRV | MCI_STATUS_S
+  | MCI_STATUS_AR | 0x134,
+.mcg_status = MCG_STATUS_MCIP | MCG_STATUS_EIPV,
+.addr = paddr,
+.misc = (MCM_ADDR_PHYS  6) | 0xc,
+};
+int r;
+
+r = kvm_set_mce(env, mce);
+if (r  0) {
+fprintf(stderr, kvm_set_mce: %s\n, strerror(errno));
+abort();
+}
+kvm_mce_broadcast_rest(env);
+}
+
+static void kvm_mce_inj_srao_memscrub(CPUState *env, target_phys_addr_t paddr)
+{
+struct kvm_x86_mce mce = {
+.bank = 9,
+.status = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN
+  | MCI_STATUS_MISCV | MCI_STATUS_ADDRV | MCI_STATUS_S
+  | 0xc0,
+.mcg_status = MCG_STATUS_MCIP | MCG_STATUS_RIPV,
+.addr = paddr,
+.misc = (MCM_ADDR_PHYS  6) | 0xc,
+};
+int r;
+
+r = kvm_set_mce(env, mce);
+if (r  0) {
+fprintf(stderr, kvm_set_mce: %s\n, strerror(errno));
+abort();
+}
+kvm_mce_broadcast_rest(env);
+}
+
+static void kvm_mce_inj_srao_memscrub2(CPUState *env, target_phys_addr_t paddr)
+{
+struct kvm_x86_mce mce = {
+.bank = 9,
+.status = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN
+  | MCI_STATUS_MISCV | MCI_STATUS_ADDRV | MCI_STATUS_S
+  | 0xc0,
+.mcg_status = MCG_STATUS_MCIP | MCG_STATUS_RIPV,
+.addr = paddr,
+.misc = (MCM_ADDR_PHYS  6) | 0xc,
+};
+
+kvm_inject_x86_mce_on(env, mce, ABORT_ON_ERROR);
+kvm_mce_broadcast_rest(env);
+}
+#endif /* KVM_CAP_MCE */
+
+static void hardware_memory_error(void)
+{
+fprintf(stderr, Hardware memory error!\n);
+exit(1);
+}
+
+int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr)
+{
+#ifdef KVM_CAP_MCE
+void *vaddr;
+ram_addr_t ram_addr;
+target_phys_addr_t paddr;
+
+if ((env-mcg_cap  MCG_SER_P)  addr
+ (code == BUS_MCEERR_AR
+|| code == BUS_MCEERR_AO)) {
+vaddr = (void *)addr;
+if (qemu_ram_addr_from_host(vaddr, ram_addr) ||
+!kvm_physical_memory_addr_from_ram(env-kvm_state, ram_addr, 
paddr)) {
+fprintf(stderr, Hardware memory error for memory used by 
+QEMU itself instead of guest system!\n);
+/* Hope we are lucky for AO MCE */
+if (code == BUS_MCEERR_AO) {
+return 0;
+} else {
+hardware_memory_error();
+}
+}
+
+if (code == BUS_MCEERR_AR) {
+/* Fake an Intel architectural Data Load SRAR UCR */
+kvm_mce_inj_srar_dataload(env, paddr);
+} else {
+/*
+ * If there is an MCE excpetion being processed, ignore
+ * this SRAO MCE
+ */
+if (!kvm_mce_in_progress(env)) {
+/* Fake an Intel architectural Memory scrubbing UCR */
+kvm_mce_inj_srao_memscrub(env, paddr);
+}
+}
+} else
+#endif /* KVM_CAP_MCE */
+{
+if (code == BUS_MCEERR_AO) {
+return 0;
+ 

[Qemu-devel] [PATCH v2 02/15] x86: Perform implicit mcg_status reset

[Jan Kiszka]

Reorder mcg_status in CPUState to achieve automatic clearing on reset.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 target-i386/cpu.h|3 ++-
 target-i386/helper.c |2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 5f1df8b..75156e7 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -687,6 +687,8 @@ typedef struct CPUX86State {
 
 uint64_t pat;
 
+uint64_t mcg_status;
+
 /* exception/interrupt handling */
 int error_code;
 int exception_is_int;
@@ -741,7 +743,6 @@ typedef struct CPUX86State {
 struct DeviceState *apic_state;
 
 uint64_t mcg_cap;
-uint64_t mcg_status;
 uint64_t mcg_ctl;
 uint64_t mce_banks[MCE_BANKS_DEF*4];
 
diff --git a/target-i386/helper.c b/target-i386/helper.c
index f0c546d..f41416f 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -101,8 +101,6 @@ void cpu_reset(CPUX86State *env)
 env-dr[7] = DR7_FIXED_1;
 cpu_breakpoint_remove_all(env, BP_CPU);
 cpu_watchpoint_remove_all(env, BP_CPU);
-
-env-mcg_status = 0;
 }
 
 void cpu_x86_close(CPUX86State *env)
-- 
1.7.1

[Qemu-devel] [PATCH v2 11/15] kvm: x86: Consolidate TCG and KVM MCE injection code

[Jan Kiszka]

This switches KVM's MCE injection path to cpu_x86_inject_mce, both for
SIGBUS and monitor initiated events. This means we prepare the MCA MSRs
in the VCPUState also for KVM.

We have to drop the MSRs writeback restrictions for this purpose which
is now safe as every uncoordinated MSR injection is removed with this
patch.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
CC: Huang Ying ying.hu...@intel.com
CC: Hidetoshi Seto seto.hideto...@jp.fujitsu.com
CC: Jin Dongming jin.dongm...@np.css.fujitsu.com
---
 target-i386/helper.c  |   34 +++-
 target-i386/kvm.c |  238 +---
 target-i386/kvm_x86.h |   25 -
 3 files changed, 37 insertions(+), 260 deletions(-)
 delete mode 100644 target-i386/kvm_x86.h

diff --git a/target-i386/helper.c b/target-i386/helper.c
index a32960c..a08309f 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -27,7 +27,6 @@
 #include exec-all.h
 #include qemu-common.h
 #include kvm.h
-#include kvm_x86.h
 #ifndef CONFIG_USER_ONLY
 #include sysemu.h
 #include monitor.h
@@ -1167,7 +1166,6 @@ void cpu_x86_inject_mce(Monitor *mon, CPUState *cenv, int 
bank,
 };
 unsigned bank_num = cenv-mcg_cap  0xff;
 CPUState *env;
-int flag = 0;
 
 if (!cenv-mcg_cap) {
 monitor_printf(mon, MCE injection not supported\n);
@@ -1187,27 +1185,19 @@ void cpu_x86_inject_mce(Monitor *mon, CPUState *cenv, 
int bank,
 return;
 }
 
-if (kvm_enabled()) {
-if (flags  MCE_INJECT_BROADCAST) {
-flag |= MCE_BROADCAST;
-}
-
-kvm_inject_x86_mce(cenv, bank, status, mcg_status, addr, misc, flag);
-} else {
-run_on_cpu(cenv, do_inject_x86_mce, params);
-if (flags  MCE_INJECT_BROADCAST) {
-params.bank = 1;
-params.status = MCI_STATUS_VAL | MCI_STATUS_UC;
-params.mcg_status = MCG_STATUS_MCIP | MCG_STATUS_RIPV;
-params.addr = 0;
-params.misc = 0;
-for (env = first_cpu; env != NULL; env = env-next_cpu) {
-if (cenv == env) {
-continue;
-}
-params.env = env;
-run_on_cpu(cenv, do_inject_x86_mce, params);
+run_on_cpu(cenv, do_inject_x86_mce, params);
+if (flags  MCE_INJECT_BROADCAST) {
+params.bank = 1;
+params.status = MCI_STATUS_VAL | MCI_STATUS_UC;
+params.mcg_status = MCG_STATUS_MCIP | MCG_STATUS_RIPV;
+params.addr = 0;
+params.misc = 0;
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+if (cenv == env) {
+continue;
 }
+params.env = env;
+run_on_cpu(cenv, do_inject_x86_mce, params);
 }
 }
 }
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 939edc8..be896dd 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -28,7 +28,6 @@
 #include hw/pc.h
 #include hw/apic.h
 #include ioport.h
-#include kvm_x86.h
 
 #ifdef CONFIG_KVM_PARA
 #include linux/kvm_para.h
@@ -193,164 +192,23 @@ static int kvm_setup_mce(CPUState *env, uint64_t 
*mcg_cap)
 return kvm_vcpu_ioctl(env, KVM_X86_SETUP_MCE, mcg_cap);
 }
 
-static int kvm_set_mce(CPUState *env, struct kvm_x86_mce *m)
+static void kvm_mce_inject(CPUState *env, target_phys_addr_t paddr, int code)
 {
-return kvm_vcpu_ioctl(env, KVM_X86_SET_MCE, m);
-}
-
-static int kvm_get_msr(CPUState *env, struct kvm_msr_entry *msrs, int n)
-{
-struct kvm_msrs *kmsrs = qemu_malloc(sizeof *kmsrs + n * sizeof *msrs);
-int r;
-
-kmsrs-nmsrs = n;
-memcpy(kmsrs-entries, msrs, n * sizeof *msrs);
-r = kvm_vcpu_ioctl(env, KVM_GET_MSRS, kmsrs);
-memcpy(msrs, kmsrs-entries, n * sizeof *msrs);
-free(kmsrs);
-return r;
-}
-
-/* FIXME: kill this and kvm_get_msr, use env-mcg_status instead */
-static int kvm_mce_in_progress(CPUState *env)
-{
-struct kvm_msr_entry msr_mcg_status = {
-.index = MSR_MCG_STATUS,
-};
-int r;
-
-r = kvm_get_msr(env, msr_mcg_status, 1);
-if (r == -1 || r == 0) {
-fprintf(stderr, Failed to get MCE status\n);
-return 0;
-}
-return !!(msr_mcg_status.data  MCG_STATUS_MCIP);
-}
-
-struct kvm_x86_mce_data
-{
-CPUState *env;
-struct kvm_x86_mce *mce;
-int abort_on_error;
-};
-
-static void kvm_do_inject_x86_mce(void *_data)
-{
-struct kvm_x86_mce_data *data = _data;
-int r;
-
-/* If there is an MCE exception being processed, ignore this SRAO MCE */
-if ((data-env-mcg_cap  MCG_SER_P) 
-!(data-mce-status  MCI_STATUS_AR)) {
-if (kvm_mce_in_progress(data-env)) {
-return;
-}
-}
-
-r = kvm_set_mce(data-env, data-mce);
-if (r  0) {
-perror(kvm_set_mce FAILED);
-if (data-abort_on_error) {
-abort();
-}
-}
-}
-
-static void kvm_inject_x86_mce_on(CPUState *env, struct kvm_x86_mce *mce,
-  int flag)
-{
-struct 

Re: [Qemu-devel] [ANNOUNCE] QEMU 0.14.0.tar.gz is available

[Kevin Wolf]

Am 17.02.2011 23:06, schrieb Anthony Liguori:
 The QEMU team is pleased to announce the availability of the 0.14.0 release.
 
 Download instructions are available at http://wiki.qemu.org/Download
 
 A detailed change log is available at http://wiki.qemu.org/Changelog/0.14
 
 On behalf of the QEMU team, I'd like to thank everyone who contributed 
 to make this release happen!

The download page has a ChangeLog link next to the 0.14 release which
points to the old page that ends with 0.12.5. You might want to change
that to point to the real 0.14 changelog.

Kevin

[Qemu-devel] OMAP3 bug: disassembler disagreed with translator

[Антон Кочков]

Seen when debugging omap3 bootrom.
A lot of messages disassebler disagrees with translator over
instruction testing

Here also modified omap3_boot.c file. I'm dont know why it is
successfully load bootrom at 0x40014000, but cant do this for 0x14000
- it always fill by zeroes.
I'm only need copy memory from already loaded rom image from
0x40014000 to 0x00014000 and nothing more.

Best regards,
Anton Kochkov.


qemu.log.gz
Description: GNU Zip compressed data


omap3_boot.c.gz
Description: GNU Zip compressed data

Re: [Qemu-devel] [PATCH 3/3 v2] block/nbd: Make the NBD block device use the AIO interface

[Nicholas Thomas]

On Thu, 2011-02-17 at 19:28 +, Nicholas Thomas wrote:

 Additional testing has revealed that this code breaks the stock
 nbd-server (the one on sourceforge) when large (well, 1.3MiB) write
 requests are sent to it.

NBD has a limit of 1MB on the size of write requests.
NBD_BUFFER_SIZE in qemu-nbd.c - and I'm sure that's what's knocking out
the standard NBD server too.

I didn't see any option to tell QEMU to split up writes to a certain
size before handing them off to the block driver, so I split the writes
up into multiple acbs. Reworked patch:


This preserves the previous behaviour where the NBD server is
unavailable or goes away during guest execution, but switches the
NBD backend to present the AIO interface instead of the sync IO
interface.

We also split write requests into 1 MiB blocks (minus request size).
This is a hard limit in the NBD servers (including qemu-nbd), but
never seemed to come up with the previous backend code.
---
 block/nbd.c |  555
++-
 1 files changed, 470 insertions(+), 85 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index c8dc763..59de69d 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1,11 +1,12 @@
 /*
- * QEMU Block driver for  NBD
+ * QEMU Block driver for  NBD - asynchronous IO
  *
  * Copyright (C) 2008 Bull S.A.S.
  * Author: Laurent Vivier laurent.viv...@bull.net
  *
  * Some parts:
  *Copyright (C) 2007 Anthony Liguori anth...@codemonkey.ws
+ *Copyright (C) 2011 Nick Thomas n...@bytemark.co.uk
  *
  * Permission is hereby granted, free of charge, to any person
obtaining a copy
  * of this software and associated documentation files (the
Software), to deal
@@ -27,66 +28,135 @@
  */
 
 #include qemu-common.h
+#include qemu_socket.h
 #include nbd.h
 #include module.h
 
 #include sys/types.h
 #include unistd.h
 
-#define EN_OPTSTR :exportname=
+#define EN_OPTSTR  :exportname=
+#define SECTOR_SIZE512
+
+/* 1MiB minus request header size */
+#define MAX_NBD_WRITE  ((1024*1024) - (4 + 4 + 8 + 8 + 4))
+
+#define DEBUG_NBD
+
+#if defined(DEBUG_NBD)
+#define logout(fmt, ...) \
+fprintf(stderr, nbd\t%-24s fmt, __func__,
##__VA_ARGS__)
+#else
+#define logout(fmt, ...) ((void)0)
+#endif
+
+
+typedef struct NBDAIOCB NBDAIOCB;
+
+typedef struct AIOReq {
+NBDAIOCB *aiocb;
+off_t iov_offset; /* Where on the iov does this req start? */
+off_t offset; /* Starting point of the read */
+
+size_t data_len;
+uint8_t flags;
+uint64_t handle;
+
+QLIST_ENTRY(AIOReq) outstanding_aio_siblings;
+QLIST_ENTRY(AIOReq) aioreq_siblings;
+} AIOReq;
+
 
 typedef struct BDRVNBDState {
 int sock;
 off_t size;
 size_t blocksize;
+
+/* Filled in by nbd_config. Store host_spec because DNS may change
*/
+bool tcp_conn;  /* True, we use TCP. False, UNIX domain sockets
*/
+char *export_name;  /* An NBD server may export several devices
*/
+char *host_spec;/* Path to socket (UNIX) or hostname/IP (TCP)
*/
+uint16_t tcp_port;
+
+/* We use these for asynchronous I/O */
+uint64_t aioreq_seq_num;
+QLIST_HEAD(outstanding_aio_head, AIOReq) outstanding_aio_head;
 } BDRVNBDState;
 
-static int nbd_open(BlockDriverState *bs, const char* filename, int
flags)
+enum AIOCBState {
+AIOCB_WRITE_UDATA,
+AIOCB_READ_UDATA,
+};
+
+struct NBDAIOCB {
+BlockDriverAIOCB common;
+
+QEMUIOVector *qiov;
+
+int64_t sector_num;
+int nb_sectors;
+
+int ret;
+enum AIOCBState aiocb_type;
+
+QEMUBH *bh;
+void (*aio_done_func)(NBDAIOCB *);
+
+int canceled;
+
+QLIST_HEAD(aioreq_head, AIOReq) aioreq_head;
+};
+
+static inline int free_aio_req(BDRVNBDState *s, AIOReq *aio_req)
 {
-BDRVNBDState *s = bs-opaque;
-uint32_t nbdflags;
+NBDAIOCB *acb = aio_req-aiocb;
+QLIST_REMOVE(aio_req, outstanding_aio_siblings);
+QLIST_REMOVE(aio_req, aioreq_siblings);
+qemu_free(aio_req);
 
+return !QLIST_EMPTY(acb-aioreq_head);
+}
+
+static int nbd_config(BDRVNBDState *s, const char* filename, int flags)
+{
 char *file;
-char *name;
-const char *host;
+char *export_name;
+const char *host_spec;
 const char *unixpath;
-int sock;
-off_t size;
-size_t blocksize;
-int ret;
 int err = -EINVAL;
 
 file = qemu_strdup(filename);
 
-name = strstr(file, EN_OPTSTR);
-if (name) {
-if (name[strlen(EN_OPTSTR)] == 0) {
+export_name = strstr(file, EN_OPTSTR);
+if (export_name) {
+if (export_name[strlen(EN_OPTSTR)] == 0) {
 goto out;
 }
-name[0] = 0;
-name += strlen(EN_OPTSTR);
+export_name[0] = 0; /* truncate 'file' */
+export_name += strlen(EN_OPTSTR);
+s-export_name = qemu_strdup(export_name);
 }
 
-if (!strstart(file, nbd:, host)) {
+/* extract the host_spec - fail if it's not nbd:* */
+if (!strstart(file, nbd:, host_spec)) {
 goto out;
 }
 
-  

Re: [Qemu-devel] [PATCH 3/3 v2] block/nbd: Make the NBD block device use the AIO interface

[Kevin Wolf]

Am 18.02.2011 13:16, schrieb Nicholas Thomas:
 On Thu, 2011-02-17 at 19:28 +, Nicholas Thomas wrote:
 
 Additional testing has revealed that this code breaks the stock
 nbd-server (the one on sourceforge) when large (well, 1.3MiB) write
 requests are sent to it.
 
 NBD has a limit of 1MB on the size of write requests.
 NBD_BUFFER_SIZE in qemu-nbd.c - and I'm sure that's what's knocking out
 the standard NBD server too.
 
 I didn't see any option to tell QEMU to split up writes to a certain
 size before handing them off to the block driver, so I split the writes
 up into multiple acbs. Reworked patch:

Splitting it up manually sounds right.

I haven't had a close look at your patches yet, but one thing that I
noticed is that your patches are corrupted by line wraps. Please
consider using git-send-email to avoid this kind of trouble or configure
your mailer so that it stops doing this.

Kevin

[Qemu-devel] Re: OMAP3 bug: disassembler disagreed with translator

[Juha.Riihimaki]

On Feb 18, 2011, at 14:08, ext Антон Кочков wrote:

 Here also modified omap3_boot.c file. I'm dont know why it is
 successfully load bootrom at 0x40014000, but cant do this for 0x14000
 - it always fill by zeroes.
 I'm only need copy memory from already loaded rom image from
 0x40014000 to 0x00014000 and nothing more.

Our OMAP3 boot emulation is a very simplified model. For example, the boot ROM 
is never mapped to Q0 region, only Q1 region -- the boot ROM execution is 
started at 0x40014000 rather than 0x00014000. There is no memory mapped at Q0 
unless you attach something to the GPMC before reset.


Regards,
Juha

[Qemu-devel] Re: [ANNOUNCE] QEMU 0.14.0.tar.gz is available

[Paolo Bonzini]

On 02/18/2011 01:08 PM, Kevin Wolf wrote:

Am 17.02.2011 23:06, schrieb Anthony Liguori:

The QEMU team is pleased to announce the availability of the 0.14.0 release.

Download instructions are available at http://wiki.qemu.org/Download

A detailed change log is available at http://wiki.qemu.org/Changelog/0.14

On behalf of the QEMU team, I'd like to thank everyone who contributed
to make this release happen!


The download page has a ChangeLog link next to the 0.14 release which
points to the old page that ends with 0.12.5. You might want to change
that to point to the real 0.14 changelog.


I fixed the immediate problem through a redirect, but the Changelog 
links in the download page should be changed respectively to 
[[ChangeLog/0.14]], [[ChangeLog/0.13]] (which doesn't exist), and 
[[ChangeLog/old]] (i.e. 0.12.5 and earlier).


The [[ChangeLog]] page should be linked from the left sidebar, probably.

Paolo

[Qemu-devel] Re: [PATCH 06/10] vmmouse: convert to qdev

[Paolo Bonzini]

On 02/17/2011 08:52 PM, Blue Swirl wrote:

On Wed, Feb 16, 2011 at 11:51 AM, Markus Armbrusterarm...@redhat.com  wrote:

Blue Swirlblauwir...@gmail.com  writes:


On Tue, Feb 15, 2011 at 12:07 PM, Markus Armbrusterarm...@redhat.com  wrote:

Anthony Liguorianth...@codemonkey.ws  writes:


On 02/12/2011 11:03 AM, Markus Armbruster wrote:

Blue Swirlblauwir...@gmail.comwrites:



Convert to qdev, also add a proper reset function.

[...]

Pointer properties are for dirty hacks only.  Is there really no better
solution?  Why does it have to be a property?



vmmouse is really just an extension to the PS2 Mouse.  It's definitely
not an ISA device.

In terms of qdev enablement, I would just make it a boolean option to
the PS2Mouse and not expose it as a top level device at all.  It
cannot exist without a PS2Mouse.


Which means making it a separate qdev is wrong.  That wrongness gave
rise to the dirty pointer property.  Pointer property serves as canary
again.

What now?


I don't find pointer property use so dirty,


See commit 036f7166.


 but I'll try to combine
the devices to see whether that makes sense.


Appreciated.


The attached patch would merge the devices, but I'm not so sure this
is the right approach. Merging seems to be OK, the registration could
be removed harder by adding a switch for known vmport values.

But vmmouse couldn't be left out of the build anymore since it would
be built per target (because of CPUState dependencies). That would be
a step backwards. Perhaps the register access helpers should be pushed
to board level.


Is there any fundamental reason why obj-i386-$(CONFIG_VMMOUSE) doesn't work?

Paolo

Re: [Qemu-devel] Re: OMAP3 bug: disassembler disagreed with translator

[Peter Maydell]

On 18 February 2011 12:24,  juha.riihim...@nokia.com wrote:
 On Feb 18, 2011, at 14:08, ext Антон Кочков wrote:

 Here also modified omap3_boot.c file. I'm dont know why it is
 successfully load bootrom at 0x40014000, but cant do this for 0x14000
 - it always fill by zeroes.
 I'm only need copy memory from already loaded rom image from
 0x40014000 to 0x00014000 and nothing more.

 Our OMAP3 boot emulation is a very simplified model. For example,
 the boot ROM is never mapped to Q0 region, only Q1 region --
 the boot ROM execution is started at 0x40014000 rather than
 0x00014000. There is no memory mapped at Q0 unless you attach
 something to the GPMC before reset.

However most boards do attach something to the GPMC;
the Beagle puts a NAND device on GPMC CS0, which means that
the GPMC will try to map NAND read/write functions on address
0 [*]. If you're trying to map a boot ROM there as well this will
clash and you need to do something clever to work however
the hardware does (presumably mapping the ROM there at startup
and unmapping the ROM later in response to some undocumented
event).

[*] Only true in the version of omap_gpmc.c in the meego
tree, but if you're doing omap3 stuff then I assume you're
using that, not upstream.

-- PMM

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Jes Sorensen]

On 02/17/11 15:39, Michael Roth wrote:
 On 02/17/2011 02:26 AM, Jes Sorensen wrote:
 On 02/16/11 18:22, Michael Roth wrote:
 worry is that we are adding a lot of complexity into QEMU on the host
 side which is going to be difficult to audit, especially with things
 like the HTML and XML processing. If we separated host side processing
 into a separate command, we could better protect ourselves against a
 situation where a rogue guest could kill QEMU and possibly exploit it on
 the host side. I think we should seriously look at moving the agent
 processing code out of main QEMU and into a standalone command, maybe
 qemu-va-host or something like that.
 
 I don't think the problem is really so fundamental...if you saw a
 host-side crash it's most likely a bug/sloppy error-handling in
 virtagent. Malformed xml (from version mismatches, transports errors,
 etc) shouldn't crash xmlrpc-c... it's using a libxml parser that just
 returns an error on unexpected xml...we just need to make sure we handle
 errors appropriately.

Hi Michael,

It may not be so fundamental, but it still makes me wary. XMLRPC
handling is quite high level and introduces the potential of errors that
are outside of our direct control. Personally I don't see the big
benefit of having virtagent terminate in QEMU, if anything it actually
makes me wary. I would quite like to see the monitor moved out of QEMU
as well and into it's own process - the simpler we make QEMU in this
regard, the more secure it will be to run. Using either a fork()
approach or simply a separate process that connects to the QEMU process
seems a very reasonable approach IMHO.

 Can you provide some details on what you ran and what the error message
 was?

It's a bit tricky, I was running a my tests over VNC on a remote system
(think trans-Atlantic latency) while having 10 people watch while I
typed the commands. It seemed that pretty much every agent command was
causing it, including ping, but unfortunately I didn't save the backtrace.

Cheers,
Jes

Re: [Qemu-devel] [PATCH 3/3 v2] block/nbd: Make the NBD block device use the AIO interface

[Nicholas Thomas]

On Fri, 2011-02-18 at 13:23 +0100, Kevin Wolf wrote:
 I haven't had a close look at your patches yet, but one thing that I
 noticed is that your patches are corrupted by line wraps. Please
 consider using git-send-email to avoid this kind of trouble or configure
 your mailer so that it stops doing this.

Argh. Right. Resending them now...

/Nick

[Qemu-devel] [PATCH] Use sigwait instead of sigwaitinfo.

[Tristan Gingold]

Fix compilation failure on Darwin.

Signed-off-by: Tristan Gingold ging...@adacore.com
---
 compatfd.c |   36 ++--
 1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/compatfd.c b/compatfd.c
index a7cebc4..bd377c4 100644
--- a/compatfd.c
+++ b/compatfd.c
@@ -26,45 +26,45 @@ struct sigfd_compat_info
 static void *sigwait_compat(void *opaque)
 {
 struct sigfd_compat_info *info = opaque;
-int err;
 sigset_t all;
 
 sigfillset(all);
 sigprocmask(SIG_BLOCK, all, NULL);
 
-do {
-siginfo_t siginfo;
+while (1) {
+int sig;
+int err;
 
-err = sigwaitinfo(info-mask, siginfo);
-if (err == -1  errno == EINTR) {
-err = 0;
-continue;
-}
-
-if (err  0) {
-char buffer[128];
+err = sigwait(info-mask, sig);
+if (err != 0) {
+if (errno == EINTR) {
+continue;
+} else {
+return NULL;
+}
+} else {
+struct qemu_signalfd_siginfo buffer;
 size_t offset = 0;
 
-memcpy(buffer, err, sizeof(err));
+memset(buffer, 0, sizeof(buffer));
+buffer.ssi_signo = sig;
+
 while (offset  sizeof(buffer)) {
 ssize_t len;
 
-len = write(info-fd, buffer + offset,
+len = write(info-fd, (char *)buffer + offset,
 sizeof(buffer) - offset);
 if (len == -1  errno == EINTR)
 continue;
 
 if (len = 0) {
-err = -1;
-break;
+return NULL;
 }
 
 offset += len;
 }
 }
-} while (err = 0);
-
-return NULL;
+}
 }
 
 static int qemu_signalfd_compat(const sigset_t *mask)
-- 
1.7.3.GIT

[Qemu-devel] [PATCH] hw/sd.c: Add missing state change for SD_STATUS, SEND_NUM_WR_BLOCKS

[Peter Maydell]

The SD_STATUS and SEND_NUM_WR_BLOCKS commands are supposed to cause
the card to send data back to the host. However sd.c was missing the
state change to sd_sendingdata_state for these commands, with the effect
that the Linux driver would either hang indefinitely waiting for
nonexistent data (pl181) or read zeroes and provoke a qemu warning
message (omap).

Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
 hw/sd.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/sd.c b/hw/sd.c
index 789ca84..5e29752 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1168,6 +1168,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
 case 13:   /* ACMD13: SD_STATUS */
 switch (sd-state) {
 case sd_transfer_state:
+sd-state = sd_sendingdata_state;
 sd-data_start = 0;
 sd-data_offset = 0;
 return sd_r1;
@@ -1182,6 +1183,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
 case sd_transfer_state:
 *(uint32_t *) sd-data = sd-blk_written;
 
+sd-state = sd_sendingdata_state;
 sd-data_start = 0;
 sd-data_offset = 0;
 return sd_r1;
-- 
1.7.1

[Qemu-devel] Re: [PATCH] Use sigwait instead of sigwaitinfo.

[Paolo Bonzini]

On 02/18/2011 02:17 PM, Tristan Gingold wrote:

Fix compilation failure on Darwin.

Signed-off-by: Tristan Gingoldging...@adacore.com
---
  compatfd.c |   36 ++--
  1 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/compatfd.c b/compatfd.c
index a7cebc4..bd377c4 100644
--- a/compatfd.c
+++ b/compatfd.c
@@ -26,45 +26,45 @@ struct sigfd_compat_info
  static void *sigwait_compat(void *opaque)
  {
  struct sigfd_compat_info *info = opaque;
-int err;
  sigset_t all;

  sigfillset(all);
  sigprocmask(SIG_BLOCK,all, NULL);

-do {
-siginfo_t siginfo;
+while (1) {
+int sig;
+int err;

-err = sigwaitinfo(info-mask,siginfo);
-if (err == -1  errno == EINTR) {
-err = 0;
-continue;
-}
-
-if (err  0) {
-char buffer[128];
+err = sigwait(info-mask,sig);
+if (err != 0) {
+if (errno == EINTR) {
+continue;
+} else {
+return NULL;
+}
+} else {
+struct qemu_signalfd_siginfo buffer;
  size_t offset = 0;

-memcpy(buffer,err, sizeof(err));
+memset(buffer, 0, sizeof(buffer));
+buffer.ssi_signo = sig;
+
  while (offset  sizeof(buffer)) {
  ssize_t len;

-len = write(info-fd, buffer + offset,
+len = write(info-fd, (char *)buffer + offset,
  sizeof(buffer) - offset);
  if (len == -1  errno == EINTR)
  continue;

  if (len= 0) {
-err = -1;
-break;
+return NULL;
  }

  offset += len;
  }
  }
-} while (err= 0);
-
-return NULL;
+}
  }

  static int qemu_signalfd_compat(const sigset_t *mask)


Looks good.

Paolo

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Anthony Liguori]

On 02/18/2011 06:45 AM, Jes Sorensen wrote:

On 02/17/11 15:39, Michael Roth wrote:
   

On 02/17/2011 02:26 AM, Jes Sorensen wrote:
 

On 02/16/11 18:22, Michael Roth wrote:
worry is that we are adding a lot of complexity into QEMU on the host
side which is going to be difficult to audit, especially with things
like the HTML and XML processing. If we separated host side processing
into a separate command, we could better protect ourselves against a
situation where a rogue guest could kill QEMU and possibly exploit it on
the host side. I think we should seriously look at moving the agent
processing code out of main QEMU and into a standalone command, maybe
qemu-va-host or something like that.
   

I don't think the problem is really so fundamental...if you saw a
host-side crash it's most likely a bug/sloppy error-handling in
virtagent. Malformed xml (from version mismatches, transports errors,
etc) shouldn't crash xmlrpc-c... it's using a libxml parser that just
returns an error on unexpected xml...we just need to make sure we handle
errors appropriately.
 

Hi Michael,

It may not be so fundamental, but it still makes me wary. XMLRPC
handling is quite high level and introduces the potential of errors that
are outside of our direct control. Personally I don't see the big
benefit of having virtagent terminate in QEMU,


Live migration.  If it's a separate daemon, then live migration gets fugly.

If xmlrpc-c is a PoS, then we ought to look at using something else.  
But let's understand what's happening first before drawing any conclusions.


Regards,

Anthony Liguori


  if anything it actually
makes me wary. I would quite like to see the monitor moved out of QEMU
as well and into it's own process - the simpler we make QEMU in this
regard, the more secure it will be to run. Using either a fork()
approach or simply a separate process that connects to the QEMU process
seems a very reasonable approach IMHO.

   

Can you provide some details on what you ran and what the error message
was?
 

It's a bit tricky, I was running a my tests over VNC on a remote system
(think trans-Atlantic latency) while having 10 people watch while I
typed the commands. It seemed that pretty much every agent command was
causing it, including ping, but unfortunately I didn't save the backtrace.

Cheers,
Jes

   

Re: [Qemu-devel] Re: Strategic decision: COW format

[Anthony Liguori]

On 02/18/2011 03:57 AM, Kevin Wolf wrote:

Am 18.02.2011 10:12, schrieb Markus Armbruster:
   

Kevin Wolfkw...@redhat.com  writes:

 

Am 15.02.2011 20:45, schrieb Chunqiang Tang:
   

Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
As you requested, I set up a wiki page for FVD at
   

http://wiki.qemu.org/Features/FVD
 

. It includes a summary of FVD, a detailed specification of FVD, and a
comparison of the design and performance of FVD and QED.
   
 

See the figure at http://wiki.qemu.org/Features/FVD/Compare . This
   

figure
 

shows that the file creation throughput of NetApp's PostMark benchmark
   

under
 

FVD is 74.9% to 215% higher than that under QED.
   

Hi Anthony,

Please let me know if more information is needed. I would appreciate your
feedback and advice on the best way to proceed with FVD.
 

Yet another file format with yet another implementation is definitely
not what we need. We should probably take some of the ideas in FVD and
consider them for qcow3.
   

Got an assumption there: that the one COW format we need must be qcow3,
i.e. an evolution of qcow2.  Needs to be justified.  If that discussion
has happened on the list already, I missed it.  If not, it's overdue,
and then we better start it right away.
 

Right. I probably wasn't very clear about what I mean with qcow3 either,
so let me try to summarize my reasoning.


The first point is an assumption that you made, too: That we want to
have only one format. I hope it's easy to agree on this, duplication is
bad and every additional format creates new maintenance burden,
especially if we're taking it serious. Until now, there were exactly two
formats for which we managed to do this, raw and qcow2. raw is more or
less for free, so with the introduction of another format, we basically
double the supported block driver code overnight (while not doubling the
number of developers).
   


Not sure what project you're following, but we've had an awful lot of 
formats before qcow2 :-)


And qcow2 was never all that special, it just was dropped in the code 
base one day.  You've put a lot of work into qcow2, but there are other 
folks that are contributing additional formats and that means more 
developers.



The consequence of having only one file format is that it must be able
to obsolete the existing ones, most notably qcow2. We can only neglect
qcow1 today because we can tell users to use qcow2. It supports
everything that qcow1 supports and more. We couldn't have done this if
qcow2 lacked features compared to qcow1.

So the one really essential requirement that I see is that we provide a
way forward for _all_ users by maintaining all of qcow2's features. This
is the only way of getting people to not stay with qcow2.


Of course, you could invent another format that implements the same
features, but I think just carefully extending qcow2 has some real
advantages.

The first is that conversion of existing images would be really easy.
Basically increment the version number in the header file and you're
done. Structures would be compatible.


qemu-img convert is a reasonable path for conversion.


  If you compare it to file systems,
I rarely ever change the file system on a non-empty partition. Even if I
wanted, it's usually just too painful. Except when I was able to use
tune2fs -j to make ext3 out of ext2, that was really easy. We can
provide the same for qcow2 to qcow3 conversion, but not with a
completely new format.

Also, while obsoleting a file format means that we need not put much
effort in its maintenance, we still need to keep the code around for
reading old images. With an extension of qcow2, it would be the same
code that is used for both versions.

Third, qcow2 already exists, is used in practice and we have put quite
some effort into QA. At least initially confidence would be higher than
in a completely new, yet untested format. Remember that with qcow3 I'm
not talking about rewriting everything, it's a careful evolution, mostly
with optional additions here and there.
   


My requirements for a new format are as followed:

1) documented, thought-out specification that is covered under and open 
license with a clear process for extension.


2) ability to add both compatible and incompatible features in a 
graceful way


3) ability to achieve performance that's close to raw.  I want our new 
format to be able to be used universally both for servers and desktops.


I think qcow2 has some misfeatures like compression and internal 
snapshots.  I think preserving those misfeatures is a mistake because I 
don't think we can satisfy the above while trying to preserve those 
features.  If the image format degrades when those features are enabled, 
then it decreases confidence in the format.


I think QED satisfies all of these today.

Regards,

Anthony Liguori


Kevin

   

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Jes Sorensen]

On 02/18/11 15:07, Anthony Liguori wrote:
 On 02/18/2011 06:45 AM, Jes Sorensen wrote:
 It may not be so fundamental, but it still makes me wary. XMLRPC
 handling is quite high level and introduces the potential of errors that
 are outside of our direct control. Personally I don't see the big
 benefit of having virtagent terminate in QEMU,
 
 Live migration.  If it's a separate daemon, then live migration gets fugly.
 
 If xmlrpc-c is a PoS, then we ought to look at using something else. 
 But let's understand what's happening first before drawing any conclusions.

Urgh, I always do my best to pretend that there is no such thing as live
migration :) Never seem to work though :(

However if there's an agent connection, it could be arranged in a way
allowing the host to reconnect to the guest agent. In that way it really
shouldn't be a big deal as long as our agent commands aren't too complex.

xmlrpc-c is probably fine, but it introduces a layer of complexity which
always makes me worried.

Cheers,
Jes

[Qemu-devel] [PATCH v4 0/4] ARM: fix Neon VRECPE and VRSQRTE instructions.

[Christophe Lyon]

These 4 patches fix the ARM Neon vrecpe and vrsqrte instructions by
matching the algorithms descibed in the ARM ARM.

With these patches, qemu passes my ARM/Neon tests.

Compared to v3, I have split patch #1 into 2 pieces (#1 and #2 here),
and fixed comments from Peter.

Patch #1 modifies softfloat by exporting floatXX_default_nan, i.e. moving all 
these definitions from softfloat-specialize.h to softfloat.h

Patch #2 introduces a new utility function float32_set_sign() to help
return the right special values (-0, -infinity), as well as new
constants: float32_infinity, float64_half, float64_256 and
float64_512.

Patch #3 uses these newly exported values and uses the VRECPE
algorithm described in the ARM ARM.

Patch #4 uses these newly exported values and uses the VRSQRTE
algorithm described in the ARM ARM.

Thanks to Peter for his careful reviews.

Christophe Lyon (4):
  softfloat: move all default NaN definitions to softfloat.h.
  softfloat: add float32_set_sign(), float32_infinity, float64_half,
float64_256 and float64_512.
  target-arm: fix support for VRECPE.
  target-arm: fix support for VRSQRTE.

 fpu/softfloat-specialize.h |   68 ---
 fpu/softfloat.h|   78 +
 target-arm/helper.c|  204 +++-
 3 files changed, 260 insertions(+), 90 deletions(-)

-- 
1.7.2.3

[Qemu-devel] [PATCH 2/4] softfloat: add float32_set_sign(), float32_infinity, float64_half, float64_256 and float64_512.

[Christophe Lyon]

These constants and utility function are needed to implement some
helpers. Defining constants avoids the need to re-compute them at
runtime.

Signed-off-by: Christophe Lyon christophe.l...@st.com
---
 fpu/softfloat.h |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index f34a938..9bd4a50 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -379,9 +379,15 @@ INLINE int float32_is_zero_or_denormal(float32 a)
 return (float32_val(a)  0x7f80) == 0;
 }
 
+INLINE float32 float32_set_sign(float32 a, int sign)
+{
+return make_float32((float32_val(a)  0x7fff) | (sign  31));
+}
+
 #define float32_zero make_float32(0)
 #define float32_one make_float32(0x3f80)
 #define float32_ln2 make_float32(0x3f317218)
+#define float32_infinity make_float32(0x7f80)
 
 
 /*
@@ -482,6 +488,9 @@ INLINE int float64_is_any_nan(float64 a)
 #define float64_zero make_float64(0)
 #define float64_one make_float64(0x3ff0LL)
 #define float64_ln2 make_float64(0x3fe62e42fefa39efLL)
+#define float64_half make_float64(0x3fe0LL)
+#define float64_256 make_float64(0x4070LL)
+#define float64_512 make_float64(0x4080LL)
 
 /*
 | The pattern for a default generated double-precision NaN.
-- 
1.7.2.3

[Qemu-devel] [PATCH 4/4] target-arm: fix support for VRSQRTE.

[Christophe Lyon]

Now use the same algorithm as described in the ARM ARM.

Signed-off-by: Christophe Lyon christophe.l...@st.com
---
 target-arm/helper.c |  121 ++
 1 files changed, 111 insertions(+), 10 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index af8b067..d770b5c 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2750,11 +2750,104 @@ float32 HELPER(recpe_f32)(float32 a, CPUState *env)
 return make_float32(val32);
 }
 
+/* The algorithm that must be used to calculate the estimate
+ * is specified by the ARM ARM.
+ */
+static float64 recip_sqrt_estimate(float64 a, CPUState *env)
+{
+float_status *s = env-vfp.standard_fp_status;
+float64 q;
+int64_t q_int;
+
+if (float64_lt(a, float64_half, s)) {
+/* range 0.25 = a  0.5 */
+
+/* a in units of 1/512 rounded down */
+/* q0 = (int)(a * 512.0);  */
+q = float64_mul(float64_512, a, s);
+q_int = float64_to_int64_round_to_zero(q, s);
+
+/* reciprocal root r */
+/* r = 1.0 / sqrt(((double)q0 + 0.5) / 512.0);  */
+q = int64_to_float64(q_int, s);
+q = float64_add(q, float64_half, s);
+q = float64_div(q, float64_512, s);
+q = float64_sqrt(q, s);
+q = float64_div(float64_one, q, s);
+} else {
+/* range 0.5 = a  1.0 */
+
+/* a in units of 1/256 rounded down */
+/* q1 = (int)(a * 256.0); */
+q = float64_mul(float64_256, a, s);
+int64_t q_int = float64_to_int64_round_to_zero(q, s);
+
+/* reciprocal root r */
+/* r = 1.0 /sqrt(((double)q1 + 0.5) / 256); */
+q = int64_to_float64(q_int, s);
+q = float64_add(q, float64_half, s);
+q = float64_div(q, float64_256, s);
+q = float64_sqrt(q, s);
+q = float64_div(float64_one, q, s);
+}
+/* r in units of 1/256 rounded to nearest */
+/* s = (int)(256.0 * r + 0.5); */
+
+q = float64_mul(q, float64_256,s );
+q = float64_add(q, float64_half, s);
+q_int = float64_to_int64_round_to_zero(q, s);
+
+/* return (double)s / 256.0;*/
+return float64_div(int64_to_float64(q_int, s), float64_256, s);
+}
+
 float32 HELPER(rsqrte_f32)(float32 a, CPUState *env)
 {
-float_status *s = env-vfp.fp_status;
-float32 one = int32_to_float32(1, s);
-return float32_div(one, float32_sqrt(a, s), s);
+float_status *s = env-vfp.standard_fp_status;
+int result_exp;
+float64 f64;
+uint32_t val;
+uint64_t val64;
+
+val = float32_val(a);
+
+if (float32_is_any_nan(a)) {
+if (float32_is_signaling_nan(a)) {
+float_raise(float_flag_invalid, s);
+}
+return float32_maybe_silence_nan(a);
+} else if (float32_is_zero_or_denormal(a)) {
+float_raise(float_flag_divbyzero, s);
+return float32_set_sign(float32_infinity, float32_is_neg(a));
+} else if (float32_is_neg(a)) {
+float_raise(float_flag_invalid, s);
+return float32_default_nan;
+} else if (float32_is_infinity(a)) {
+return float32_zero;
+}
+
+/* Normalize to a double-precision value between 0.25 and 1.0,
+ * preserving the parity of the exponent.  */
+if ((val  0x80) == 0) {
+f64 = make_float64(((uint64_t)(val  0x8000)  32)
+   | (0x3feULL  52)
+   | ((uint64_t)(val  0x7f)  29));
+} else {
+f64 = make_float64(((uint64_t)(val  0x8000)  32)
+   | (0x3fdULL  52)
+   | ((uint64_t)(val  0x7f)  29));
+}
+
+result_exp = (380 - ((val  0x7f80)  23)) / 2;
+
+f64 = recip_sqrt_estimate(f64, env);
+
+val64 = float64_val(f64);
+
+val = ((val64  63)   0x8000)
+| ((result_exp  0xff)  23)
+| ((val64  29)   0x7f);
+return make_float32(val);
 }
 
 uint32_t HELPER(recpe_u32)(uint32_t a, CPUState *env)
@@ -2775,13 +2868,21 @@ uint32_t HELPER(recpe_u32)(uint32_t a, CPUState *env)
 
 uint32_t HELPER(rsqrte_u32)(uint32_t a, CPUState *env)
 {
-float_status *s = env-vfp.fp_status;
-float32 tmp;
-tmp = int32_to_float32(a, s);
-tmp = float32_scalbn(tmp, -32, s);
-tmp = helper_rsqrte_f32(tmp, env);
-tmp = float32_scalbn(tmp, 31, s);
-return float32_to_int32(tmp, s);
+float64 f64;
+
+if ((a  0xc000) == 0) return 0x;
+
+if (a  0x8000) {
+f64 = make_float64((0x3feULL  52)
+   | ((uint64_t)(a  0x7fff)  21));
+} else { /* bits 31-30 == '01' */
+f64 = make_float64((0x3fdULL  52)
+   | ((uint64_t)(a  0x3fff)  22));
+}
+
+f64 = recip_sqrt_estimate(f64, env);
+
+return 0x8000 | ((float64_val(f64)  21)  0x7fff);
 }
 
 void HELPER(set_teecr)(CPUState *env, uint32_t val)
-- 
1.7.2.3

[Qemu-devel] [PATCH 3/4] target-arm: fix support for VRECPE.

[Christophe Lyon]

Now use the same algorithm as described in the ARM ARM.

Signed-off-by: Christophe Lyon christophe.l...@st.com
---
 target-arm/helper.c |   83 +++---
 1 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/target-arm/helper.c b/target-arm/helper.c
index 7f63a28..af8b067 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2687,13 +2687,67 @@ float32 HELPER(rsqrts_f32)(float32 a, float32 b, 
CPUState *env)
 
 /* NEON helpers.  */
 
-/* TODO: The architecture specifies the value that the estimate functions
-   should return.  We return the exact reciprocal/root instead.  */
+/* The algorithm that must be used to calculate the estimate
+ * is specified by the ARM ARM.
+ */
+static float64 recip_estimate(float64 a, CPUState *env)
+{
+float_status *s = env-vfp.standard_fp_status;
+/* q = (int)(a * 512.0) */
+float64 q = float64_mul(float64_512, a, s);
+int64_t q_int = float64_to_int64_round_to_zero(q, s);
+
+/* r = 1.0 / (((double)q + 0.5) / 512.0) */
+q = int64_to_float64(q_int, s);
+q = float64_add(q, float64_half, s);
+q = float64_div(q, float64_512, s);
+q = float64_div(float64_one, q, s);
+
+/* s = (int)(256.0 * r + 0.5) */
+q = float64_mul(q, float64_256, s);
+q = float64_add(q, float64_half, s);
+q_int = float64_to_int64_round_to_zero(q, s);
+
+/* return (double)s / 256.0 */
+return float64_div(int64_to_float64(q_int, s), float64_256, s);
+}
+
 float32 HELPER(recpe_f32)(float32 a, CPUState *env)
 {
-float_status *s = env-vfp.fp_status;
-float32 one = int32_to_float32(1, s);
-return float32_div(one, a, s);
+float_status *s = env-vfp.standard_fp_status;
+float64 f64;
+uint32_t val32 = float32_val(a);
+
+int result_exp;
+int a_exp = (val32   0x7f80)  23;
+int sign = val32  0x8000;
+
+if (float32_is_any_nan(a)) {
+if (float32_is_signaling_nan(a)) {
+float_raise(float_flag_invalid, s);
+}
+return float32_maybe_silence_nan(a);
+} else if (float32_is_infinity(a)) {
+return float32_set_sign(float32_zero, float32_is_neg(a));
+} else if (float32_is_zero_or_denormal(a)) {
+float_raise(float_flag_divbyzero, s);
+return float32_set_sign(float32_infinity, float32_is_neg(a));
+} else if (a_exp = 253) {
+float_raise(float_flag_underflow, s);
+return float32_set_sign(float32_zero, float32_is_neg(a));
+}
+
+f64 = make_float64((0x3feULL  52)
+   | ((int64_t)(val32  0x7f)  29));
+
+result_exp = 253 - a_exp;
+
+f64 = recip_estimate(f64, env);
+
+val32 = sign
+| ((result_exp  0xff)  23)
+| ((float64_val(f64)  29)  0x7f);
+return make_float32(val32);
 }
 
 float32 HELPER(rsqrte_f32)(float32 a, CPUState *env)
@@ -2705,13 +2759,18 @@ float32 HELPER(rsqrte_f32)(float32 a, CPUState *env)
 
 uint32_t HELPER(recpe_u32)(uint32_t a, CPUState *env)
 {
-float_status *s = env-vfp.fp_status;
-float32 tmp;
-tmp = int32_to_float32(a, s);
-tmp = float32_scalbn(tmp, -32, s);
-tmp = helper_recpe_f32(tmp, env);
-tmp = float32_scalbn(tmp, 31, s);
-return float32_to_int32(tmp, s);
+float64 f64;
+
+if ((a  0x8000) == 0) {
+return 0x;
+}
+
+f64 = make_float64((0x3feULL  52)
+   | ((int64_t)(a  0x7fff)  21));
+
+f64 = recip_estimate (f64, env);
+
+return 0x8000 | ((float64_val(f64)  21)  0x7fff);
 }
 
 uint32_t HELPER(rsqrte_u32)(uint32_t a, CPUState *env)
-- 
1.7.2.3

[Qemu-devel] [PATCH 1/4] softfloat: move all default NaN definitions to softfloat.h.

[Christophe Lyon]

These special values are needed to implement some helper functions,
which return/use these values in some cases.

Signed-off-by: Christophe Lyon christophe.l...@st.com
---
 fpu/softfloat-specialize.h |   68 ---
 fpu/softfloat.h|   69 
 2 files changed, 69 insertions(+), 68 deletions(-)

diff --git a/fpu/softfloat-specialize.h b/fpu/softfloat-specialize.h
index 2d025bf..adc5ada 100644
--- a/fpu/softfloat-specialize.h
+++ b/fpu/softfloat-specialize.h
@@ -30,12 +30,6 @@ these four paragraphs for those parts of this code that are 
retained.
 
 =*/
 
-#if defined(TARGET_MIPS) || defined(TARGET_SH4)
-#define SNAN_BIT_IS_ONE1
-#else
-#define SNAN_BIT_IS_ONE0
-#endif
-
 /*
 | Raises the exceptions specified by `flags'.  Floating-point traps can be
 | defined here if desired.  It is currently not possible for such a trap
@@ -57,17 +51,6 @@ typedef struct {
 } commonNaNT;
 
 /*
-| The pattern for a default generated half-precision NaN.
-**/
-#if defined(TARGET_ARM)
-#define float16_default_nan make_float16(0x7E00)
-#elif SNAN_BIT_IS_ONE
-#define float16_default_nan make_float16(0x7DFF)
-#else
-#define float16_default_nan make_float16(0xFE00)
-#endif
-
-/*
 | Returns 1 if the half-precision floating-point value `a' is a quiet
 | NaN; otherwise returns 0.
 **/
@@ -158,19 +141,6 @@ static float16 commonNaNToFloat16(commonNaNT a 
STATUS_PARAM)
 }
 
 /*
-| The pattern for a default generated single-precision NaN.
-**/
-#if defined(TARGET_SPARC)
-#define float32_default_nan make_float32(0x7FFF)
-#elif defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_ALPHA)
-#define float32_default_nan make_float32(0x7FC0)
-#elif SNAN_BIT_IS_ONE
-#define float32_default_nan make_float32(0x7FBF)
-#else
-#define float32_default_nan make_float32(0xFFC0)
-#endif
-
-/*
 | Returns 1 if the single-precision floating-point value `a' is a quiet
 | NaN; otherwise returns 0.
 **/
@@ -413,19 +383,6 @@ static float32 propagateFloat32NaN( float32 a, float32 b 
STATUS_PARAM)
 }
 
 /*
-| The pattern for a default generated double-precision NaN.
-**/
-#if defined(TARGET_SPARC)
-#define float64_default_nan make_float64(LIT64( 0x7FFF ))
-#elif defined(TARGET_PPC) || defined(TARGET_ARM) || defined(TARGET_ALPHA)
-#define float64_default_nan make_float64(LIT64( 0x7FF8 ))
-#elif SNAN_BIT_IS_ONE
-#define float64_default_nan make_float64(LIT64( 0x7FF7 ))
-#else
-#define float64_default_nan make_float64(LIT64( 0xFFF8 ))
-#endif
-
-/*
 | Returns 1 if the double-precision floating-point value `a' is a quiet
 | NaN; otherwise returns 0.
 **/
@@ -564,19 +521,6 @@ static float64 propagateFloat64NaN( float64 a, float64 b 
STATUS_PARAM)
 #ifdef FLOATX80
 
 /*
-| The pattern for a default generated extended double-precision NaN.  The
-| `high' and `low' values hold the most- and least-significant bits,
-| respectively.
-**/
-#if SNAN_BIT_IS_ONE
-#define floatx80_default_nan_high 0x7FFF
-#define floatx80_default_nan_low  LIT64( 0xBFFF )
-#else
-#define floatx80_default_nan_high 0x
-#define floatx80_default_nan_low  LIT64( 0xC000 )
-#endif
-
-/*
 | Returns 1 if the extended double-precision floating-point value `a' is a
 | quiet NaN; otherwise returns 0. This slightly differs from the same
 | function for other types as floatx80 has an explicit bit.
@@ -728,18 +672,6 @@ static floatx80 propagateFloatx80NaN( floatx80 a, floatx80 
b STATUS_PARAM)
 #ifdef FLOAT128
 
 /*
-| The pattern for a default generated 

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Anthony Liguori]

On 02/18/2011 08:30 AM, Jes Sorensen wrote:

On 02/18/11 15:07, Anthony Liguori wrote:
   

On 02/18/2011 06:45 AM, Jes Sorensen wrote:
 

It may not be so fundamental, but it still makes me wary. XMLRPC
handling is quite high level and introduces the potential of errors that
are outside of our direct control. Personally I don't see the big
benefit of having virtagent terminate in QEMU,
   

Live migration.  If it's a separate daemon, then live migration gets fugly.

If xmlrpc-c is a PoS, then we ought to look at using something else.
But let's understand what's happening first before drawing any conclusions.
 

Urgh, I always do my best to pretend that there is no such thing as live
migration :) Never seem to work though :(

However if there's an agent connection, it could be arranged in a way
allowing the host to reconnect to the guest agent. In that way it really
shouldn't be a big deal as long as our agent commands aren't too complex.
   


Oh, but they'll be nice and complex :-)  What happens if you do a live 
migration in the middle of doing a live backup?  You'll end up with the 
guest waiting to be told that it's okay to unfreeze itself only to never 
be told.


Terminating in QEMU means we can do intelligent things like delay live 
migration convergence, save state, etc.


Regards,

Anthony Liguori


xmlrpc-c is probably fine, but it introduces a layer of complexity which
always makes me worried.

Cheers,
Jes
   

[Qemu-devel] [RFC PATCH] block: Fix eject -f for locked devices

[Markus Armbruster]

From 8cd4978c9be6ff2bcc414bb1c1b258b96b9a74c1 Mon Sep 17 00:00:00 2001
From: Markus Armbruster arm...@redhat.com
Date: Fri, 18 Feb 2011 15:54:02 +0100

After forcefully ejecting media locked by the guest, you can't ever
again insert new media.

Example:

(qemu) info block
hda: type=hd removable=0 file=test.img ro=0 drv=raw encrypted=0
cd: type=cdrom removable=1 locked=1 file=x.iso ro=0 drv=raw encrypted=0
(qemu) eject cd
Device 'cd' is locked
(qemu) eject -f cd
(qemu) info block
hda: type=hd removable=0 file=test.img ro=0 drv=raw encrypted=0
cd: type=cdrom removable=1 locked=1 [not inserted]
(qemu) change cd x.iso
Device 'cd' is locked

Signed-off-by: Markus Armbruster arm...@redhat.com
---
I'm not entirely sure this is the appropriate fix, and that's why
there's RFC in the subject.

Both IDE and SCSI devices expose their drive's BlockDriverState member
locked to the guest via mode sense.

What does real hardware do when I force-eject media (typically by
rummaging in that little hole with a paperclip)?  Does it actively
notify the OS?  Does mode sense change?

A possible alternative fix is to make do_change_block() ignore
bdrv_is_locked() when inserting media into an empty drive.

 block.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index b476479..295cf7b 100644
--- a/block.c
+++ b/block.c
@@ -682,6 +682,7 @@ void bdrv_close(BlockDriverState *bs)
 }
 
 /* call the change callback */
+bs-locked = 0;
 bs-media_changed = 1;
 if (bs-change_cb)
 bs-change_cb(bs-change_opaque, CHANGE_MEDIA);
-- 
1.7.2.3

Re: [Qemu-devel] [PATCH REBASE/RESEND 0/4] Auto-document qdev devices

[Anthony Liguori]

On 02/18/2011 02:53 AM, Markus Armbruster wrote:

Anthony Liguorianth...@codemonkey.ws  writes:

   

On 02/04/2011 12:18 AM, Amit Shah wrote:
 

Hello,

This is yet another rebase of the patchset I'd sent earlier.

The usual notes apply: this is just the start, just getting the
framework in place and a few examples so that people can then pick up
and start documenting their devices and options.  We want to see all
of the devices covered, and hopefully turn on build_bug_on() on an
empty doc string.

Maintainers should perhaps also look for patches that introduce
options without documentation.

That's the long-term goal (0.15-final).  For short-term, I'll be
preparing follow-on patches that add doc strings for a few more
options and perhaps bug people based on git history as to what
documentation is to be added for some options.  Also to incorporate
Markus's comments on beautifying output.

The earlier this patchset goes in the better since it'll reduce
conflicts and rebases needed.

If this looks acceptable, please apply!

   

I think we need to approach this in such a way that we generate not
only inline documentation but out of line documentation.

We need a way to extract the docs into a file.  That could mean having
something like a .hx file or just doing some clever things with grep
DEFINE_PROP.
 

Or stupid things with linking docs into a simple program that prints
them.

Anyway, let's not overengineer now.  This patch is a step forward: the
user gets help where there was none before.  It doesn't prejudice
further steps forward, such as putting the help information to
additional uses.
   


The blocker for me is the introduction of empty strings.   Doc 
extraction is a nice-to-have but I'd be inclined to merge w/o it.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH REBASE/RESEND 1/4] qdev: Add a description field for qdev properties for documentation

[Anthony Liguori]

On 02/18/2011 02:59 AM, Markus Armbruster wrote:

Anthony Liguorianth...@codemonkey.ws  writes:

   

On 02/17/2011 07:06 AM, Amit Shah wrote:
 

On (Tue) 15 Feb 2011 [10:43:42], Anthony Liguori wrote:


   

   #define DEFINE_BLOCK_PROPERTIES(_state, _conf)  \
-DEFINE_PROP_DRIVE(drive, _state, _conf.bs),   \
+DEFINE_PROP_DRIVE(drive, _state, _conf.bs, ),   \
   DEFINE_PROP_UINT16(logical_block_size, _state,\
-   _conf.logical_block_size, 512),  \
+   _conf.logical_block_size, 512, ),  \
   DEFINE_PROP_UINT16(physical_block_size, _state,   \
-   _conf.physical_block_size, 512), \
-DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0),  \
-DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0),\
-DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1),\
+   _conf.physical_block_size, 512, ), \
+DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0, ), \
+DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0, ), \
+DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1, ), \
   DEFINE_PROP_UINT32(discard_granularity, _state, \
-   _conf.discard_granularity, 0)
+   _conf.discard_granularity, 0, )

   

This is pretty horribly ugly.  If we were going this, we should at
least introduce new defines that include a documentation field and
not just add empty documentation fields.

 

We've discussed this in the past.  Once this patch series gets in,
I'll work to fill in the documentation here along with the
maintainers.

   

It means you're touching everything twice instead of touching
everything once.  That's unnecessary churn and blame breakage.

It's still just as greppable if you use a new name.
 

What names would you suggest?  DEFINE_PROP_FOO_WITH_DOCS()?  For all
fifteenFOOs?  Not a good idea, because the longer name makes doing
the right thing even less attractive.  We better encourage doing the
right thing.
   


Okay, make it a shorter name then DEFPROP_UINT32.

Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Gerd Hoffmann]

  Hi,


It may not be so fundamental, but it still makes me wary. XMLRPC
handling is quite high level and introduces the potential of errors that
are outside of our direct control. Personally I don't see the big
benefit of having virtagent terminate in QEMU,


Live migration. If it's a separate daemon, then live migration gets fugly.

If xmlrpc-c is a PoS, then we ought to look at using something else.


Anyone looked at using json instead?  We already have a bunch of code 
for that thanks to QMP ...


cheers,
  Gerd

[Qemu-devel] [PATCH 0/5] TPM device emulation

[Andreas Niederl]

Hi,

This patch series introduces TPM device emulation in QEMU.

The emulation is divided into a device frontend implementing the TPM TIS 1.2
interface (specification available at [1]) and a framework for implementation
specific backend drivers which are used by the frontend.

A backend driver for direct passthrough of a TPM device using the host driver
on a Linux system is provided and is enabled by passing
'-tpm type=host,path=...,id=...' to QEMU.

Since the Linux TPM driver requires blocking I/O to the TPM device, a custom
thread or a threadlet (using the threadlet patch series on this list, see
last patch) is needed for handling I/O operations in the host backend.


The frontend is integrated into the qdev device framework and can be enabled
using the '-device' argument specifying a valid backend driver, e.g.:
  qemu ... -tpm type=host,path=/dev/tpm0,id=tpm0 -device tpm,backend=tpm0

When the frontend is enabled, a SSDT ACPI table containing the device
description for hotplugging is loaded using the fw_cfg runtime configuration
interface to SeaBIOS.


This device emulation can be tested by loading an image and installing the
jTPMTools and the jTSS stack which ships a set of unit tests itself and is
available on [2].

Testing can also be done using the character device provided by the
TPM emulator [3] with the tpmd_dev kernel module.


This patch series is used in the acTvSM trusted virtualization platform which
also is available on [2].


Regards,
Andreas Niederl

[1] https://www.trustedcomputinggroup.org/
[2] http://trustedjava.sourceforge.net/
[3] http://tpm-emulator.berlios.de/


Andreas Niederl (5):
  Add TPM 1.2 device interface
  Provide SSDT for enabled TPM device
  Add TPM host passthrough device backend.
  Add configure script and command line options for TPM interface.
  Adapt TPM host backend to use threadlets

 Makefile.objs |3 +
 Makefile.target   |3 +
 configure |9 +
 hw/acpi.c |   28 ++
 hw/pc.h   |1 +
 hw/tpm.h  |   24 ++
 hw/tpm_acpi.c |   40 +++
 hw/tpm_backend.c  |   78 ++
 hw/tpm_host_backend.c |  235 
 hw/tpm_int.h  |   56 
 hw/tpm_ssdt.dsl   |   55 
 hw/tpm_ssdt.hex   |   41 +++
 hw/tpm_tis.c  |  706 +
 qemu-config.c |   16 ++
 qemu-config.h |1 +
 qemu-options.hx   |6 +
 rules.mak |7 +-
 vl.c  |   45 +++
 18 files changed, 1353 insertions(+), 1 deletions(-)
 create mode 100644 hw/tpm.h
 create mode 100644 hw/tpm_acpi.c
 create mode 100644 hw/tpm_backend.c
 create mode 100644 hw/tpm_host_backend.c
 create mode 100644 hw/tpm_int.h
 create mode 100644 hw/tpm_ssdt.dsl
 create mode 100644 hw/tpm_ssdt.hex
 create mode 100644 hw/tpm_tis.c

-- 
1.7.4.1

[Qemu-devel] [PATCH 3/5] Add TPM host passthrough device backend.

[Andreas Niederl]

A separate thread is used for I/O to the host TPM device because the Linux TPM
driver does not allow non-blocking I/O.

Signed-off-by: Andreas Niederl andreas.nied...@iaik.tugraz.at
---
 Makefile.objs |5 +-
 hw/tpm_backend.c  |1 +
 hw/tpm_host_backend.c |  282 +
 hw/tpm_int.h  |3 +
 4 files changed, 290 insertions(+), 1 deletions(-)
 create mode 100644 hw/tpm_host_backend.c

diff --git a/Makefile.objs b/Makefile.objs
index 6c78453..55fd6b5 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -284,7 +284,10 @@ hw-obj-$(CONFIG_VIRTFS) += virtio-9p-local.o 
virtio-9p-xattr.o
 hw-obj-$(CONFIG_VIRTFS) += virtio-9p-xattr-user.o virtio-9p-posix-acl.o
 
 # TPM passthrough device
-hw-obj-$(CONFIG_TPM) += tpm_tis.o tpm_backend.o
+hw-obj-$(CONFIG_TPM) += tpm_tis.o tpm_backend.o tpm_host_backend.o
+ifndef CONFIG_THREAD
+common-obj-$(CONFIG_TPM) += qemu-thread.o
+endif
 
 ##
 # libdis
diff --git a/hw/tpm_backend.c b/hw/tpm_backend.c
index b87c089..41dbfd4 100644
--- a/hw/tpm_backend.c
+++ b/hw/tpm_backend.c
@@ -40,6 +40,7 @@ typedef struct {
 } TPMDriverTable;
 
 static const TPMDriverTable driver_table[] = {
+{ .name = host, .open = qemu_tpm_host_open },
 };
 
 int qemu_tpm_add(QemuOpts *opts) {
diff --git a/hw/tpm_host_backend.c b/hw/tpm_host_backend.c
new file mode 100644
index 000..4ae9deb
--- /dev/null
+++ b/hw/tpm_host_backend.c
@@ -0,0 +1,282 @@
+/*
+ * tpm_host_backend.c - TPM host passthrough backend driver
+ *
+ * Copyright (C) 2011 IAIK, Graz University of Technology
+ *
+ * Author: Andreas Niederl andreas.nied...@iaik.tugraz.at
+ *
+ * A custom thread is used for asynchronous I/O to the host TPM device
+ * because the Linux TPM driver does not allow non-blocking I/O.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+
+
+#include errno.h
+#include signal.h
+
+#include qemu-common.h
+#include qemu-thread.h
+
+#include hw/tpm_int.h
+
+
+typedef struct {
+QemuThread id;
+QemuMutex  lock;
+QemuCond   send_command;
+} TPMThread;
+
+#define STATUS_DONE(1  1)
+#define STATUS_IN_PROGRESS (1  0)
+#define STATUS_IDLE 0
+
+typedef struct {
+TPMDriver common;
+
+TPMThread thread;
+
+uint8_t   send_status;
+uint8_t   recv_status;
+
+int32_t  send_len;
+int32_t  recv_len;
+
+int fd;
+} TPMHostDriver;
+
+static int tpm_host_send(TPMDriver *drv, uint8_t locty, uint32_t len)
+{
+TPMHostDriver *hdrv = DO_UPCAST(TPMHostDriver, common, drv);
+int n = 0;
+
+drv-locty = locty;
+
+qemu_mutex_lock(hdrv-thread.lock);
+switch (hdrv-send_status) {
+case STATUS_IN_PROGRESS:
+break;
+case STATUS_IDLE:
+hdrv-send_len = len;
+hdrv-recv_len = TPM_MAX_PKT;
+/* asynchronous send */
+n = 1;
+qemu_cond_signal( hdrv-thread.send_command);
+break;
+case STATUS_DONE:
+n = hdrv-send_len;
+hdrv-send_status = STATUS_IDLE;
+break;
+default:
+n = -1;
+fprintf(stderr,
+tpm host backend: internal error on send status %d\n,
+hdrv-send_status);
+break;
+}
+qemu_mutex_unlock(hdrv-thread.lock);
+
+return n;
+}
+
+static int tpm_host_recv(TPMDriver *drv, uint8_t locty, uint32_t len)
+{
+TPMHostDriver *hdrv = DO_UPCAST(TPMHostDriver, common, drv);
+int n = 0;
+
+drv-locty = locty;
+
+qemu_mutex_lock(hdrv-thread.lock);
+switch (hdrv-recv_status) {
+case STATUS_IN_PROGRESS:
+break;
+case STATUS_IDLE:
+break;
+case STATUS_DONE:
+hdrv-recv_status = STATUS_IDLE;
+n = hdrv-recv_len;
+break;
+default:
+n = -1;
+fprintf(stderr,
+tpm host backend: internal error on recv status %d\n,
+hdrv-recv_status);
+break;
+}
+qemu_mutex_unlock(hdrv-thread.lock);
+
+return n;
+}
+
+
+/* borrowed from qemu-char.c */
+static int unix_write(int fd, const uint8_t *buf, uint32_t len)
+{
+int ret, len1;
+
+len1 = len;
+while (len1  0) {
+ret = write(fd, buf, len1);
+if (ret  0) {
+if (errno != EINTR  errno != EAGAIN)
+return -1;
+} else if (ret == 0) {
+break;
+} else {
+buf  += ret;
+len1 -= ret;
+}
+}
+return len - len1;
+}
+
+static int unix_read(int fd, uint8_t *buf, uint32_t len)
+{
+int ret, len1;
+uint8_t *buf1;
+
+len1 = len;
+buf1 = buf;
+while ((len1  0)  (ret = read(fd, buf1, len1)) != 0) {
+if (ret  

[Qemu-devel] [PATCH 2/5] Provide SSDT for enabled TPM device

[Andreas Niederl]

Signed-off-by: Andreas Niederl andreas.nied...@iaik.tugraz.at
---
 Makefile.target |3 +++
 hw/acpi.c   |   28 
 hw/pc.h |1 +
 hw/tpm.h|2 ++
 hw/tpm_acpi.c   |   40 
 hw/tpm_ssdt.dsl |   55 +++
 hw/tpm_ssdt.hex |   41 +
 hw/tpm_tis.c|1 +
 rules.mak   |7 ++-
 vl.c|   23 +++
 10 files changed, 200 insertions(+), 1 deletions(-)
 create mode 100644 hw/tpm_acpi.c
 create mode 100644 hw/tpm_ssdt.dsl
 create mode 100644 hw/tpm_ssdt.hex

diff --git a/Makefile.target b/Makefile.target
index 5a0fd40..33ffe19 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -211,6 +211,9 @@ obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
 # Inter-VM PCI shared memory
 obj-$(CONFIG_KVM) += ivshmem.o
 
+# TPM acpi support
+obj-$(CONFIG_TPM) += tpm_acpi.o
+
 # Hardware support
 obj-i386-y += vga.o
 obj-i386-y += mc146818rtc.o i8259.o pc.o
diff --git a/hw/acpi.c b/hw/acpi.c
index 8071e7b..93656c5 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -35,6 +35,34 @@ struct acpi_table_header
 char *acpi_tables;
 size_t acpi_tables_len;
 
+
+/*
+ * add a table directly (e.g. iasl C source output)
+ */
+int acpi_table_add_raw(const char *t, uint32_t length)
+{
+char *p;
+
+if (!acpi_tables) {
+acpi_tables_len = sizeof(uint16_t);
+acpi_tables = qemu_mallocz(acpi_tables_len);
+}
+acpi_tables = qemu_realloc(acpi_tables,
+   acpi_tables_len + sizeof(uint16_t) + length);
+p = acpi_tables + acpi_tables_len;
+acpi_tables_len += sizeof(uint16_t) + length;
+
+*(uint16_t*)p = cpu_to_le32(length);
+p += sizeof(uint16_t);
+
+memcpy(p, t, length);
+
+/* increase number of tables */
+(*(uint16_t*)acpi_tables) =
+cpu_to_le32(le32_to_cpu(*(uint16_t*)acpi_tables) + 1);
+return 0;
+}
+
 static int acpi_checksum(const uint8_t *data, int len)
 {
 int sum, i;
diff --git a/hw/pc.h b/hw/pc.h
index d5d2f42..56ba5fc 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -118,6 +118,7 @@ extern size_t acpi_tables_len;
 
 void acpi_bios_init(void);
 int acpi_table_add(const char *table_desc);
+int acpi_table_add_raw(const char *table, uint32_t length);
 
 /* acpi_piix.c */
 
diff --git a/hw/tpm.h b/hw/tpm.h
index f3e1395..5dd40c8 100644
--- a/hw/tpm.h
+++ b/hw/tpm.h
@@ -19,4 +19,6 @@
 
 int qemu_tpm_add(QemuOpts *opts);
 
+int qemu_tpm_acpi_init(void);
+
 #endif /* TPM_H */
diff --git a/hw/tpm_acpi.c b/hw/tpm_acpi.c
new file mode 100644
index 000..8cfa98f
--- /dev/null
+++ b/hw/tpm_acpi.c
@@ -0,0 +1,40 @@
+/*
+ * tpm_acpi.c - ACPI integration for TPM device emulation
+ *
+ * Copyright (C) 2011 IAIK, Graz University of Technology
+ *
+ * Author: Andreas Niederl andreas.nied...@iaik.tugraz.at
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+
+#include hw/pc.h
+#include hw/tpm.h
+
+/*
+ * Add SSDT entry for TPM device
+ *
+ * Only one such entry is possible because it specifies a fixed MMIO address
+ * as required by the TIS 1.2 specification.
+ */
+int qemu_tpm_acpi_init(void)
+{
+int ret = 0;
+#ifdef TARGET_I386
+static int init = 0;
+
+#include hw/tpm_ssdt.hex
+
+if (!init) {
+ret  = acpi_table_add_raw((char*)AmlCode, sizeof(AmlCode));
+init = 1;
+}
+#endif
+
+return ret;
+}
+
diff --git a/hw/tpm_ssdt.dsl b/hw/tpm_ssdt.dsl
new file mode 100644
index 000..d9a48a7
--- /dev/null
+++ b/hw/tpm_ssdt.dsl
@@ -0,0 +1,55 @@
+/*
+ * ACPI SSDT ASL definition for TPM device emulation
+ *
+ * Copyright (C) 2011 IAIK, Graz University of Technology
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License version 2 as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see http://www.gnu.org/licenses/
+ */
+
+DefinitionBlock (
+tpm-ssdt.aml,// Output Filename
+SSDT, // Signature
+0x01,   // DSDT Compliance Revision
+BXPC, // OEMID
+TPM-SSDT, // TABLE ID
+0x1 // OEM Revision
+)
+{
+
+Scope(\_SB) {
+/* Pass-through TPM device with emulated TPM TIS interface */
+Device (TPM) {
+Name (_HID, EisaID (ATM1200))
+Name (_CID, EisaId (PNP0C31))
+Name (_STR, 

[Qemu-devel] [PATCH 1/5] Add TPM 1.2 device interface

[Andreas Niederl]

This implementation is based on the TPM 1.2 interface for virtualized TPM
devices from the Xen-4.0.0 ioemu-qemu-xen fork.

A backend driver infrastructure is provided to be able to use different
device backends.

Signed-off-by: Andreas Niederl andreas.nied...@iaik.tugraz.at
---
 Makefile.objs|3 +
 hw/tpm.h |   22 ++
 hw/tpm_backend.c |   77 ++
 hw/tpm_int.h |   53 
 hw/tpm_tis.c |  705 ++
 5 files changed, 860 insertions(+), 0 deletions(-)
 create mode 100644 hw/tpm.h
 create mode 100644 hw/tpm_backend.c
 create mode 100644 hw/tpm_int.h
 create mode 100644 hw/tpm_tis.c

diff --git a/Makefile.objs b/Makefile.objs
index b21f9d3..6c78453 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -283,6 +283,9 @@ hw-obj-$(CONFIG_REALLY_VIRTFS) += virtio-9p-debug.o
 hw-obj-$(CONFIG_VIRTFS) += virtio-9p-local.o virtio-9p-xattr.o
 hw-obj-$(CONFIG_VIRTFS) += virtio-9p-xattr-user.o virtio-9p-posix-acl.o
 
+# TPM passthrough device
+hw-obj-$(CONFIG_TPM) += tpm_tis.o tpm_backend.o
+
 ##
 # libdis
 # NOTE: the disassembler code is only needed for debugging
diff --git a/hw/tpm.h b/hw/tpm.h
new file mode 100644
index 000..f3e1395
--- /dev/null
+++ b/hw/tpm.h
@@ -0,0 +1,22 @@
+/*
+ * tpm.h - Interface for adding TPM backend drivers
+ *
+ * Copyright (C) 2011 IAIK, Graz University of Technology
+ *
+ * Author: Andreas Niederl andreas.nied...@iaik.tugraz.at
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+
+#ifndef TPM_H
+#define TPM_H
+
+#include qemu-option.h
+
+int qemu_tpm_add(QemuOpts *opts);
+
+#endif /* TPM_H */
diff --git a/hw/tpm_backend.c b/hw/tpm_backend.c
new file mode 100644
index 000..b87c089
--- /dev/null
+++ b/hw/tpm_backend.c
@@ -0,0 +1,77 @@
+/*
+ * tpm_backend.c - TPM backend driver framework
+ *
+ * Copyright (C) 2011 IAIK, Graz University of Technology
+ *
+ * Author: Andreas Niederl andreas.nied...@iaik.tugraz.at
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+
+
+#include qemu-option.h
+
+#include hw/tpm.h
+#include hw/tpm_int.h
+
+
+static QLIST_HEAD(, TPMDriver) tpm_drivers =
+QLIST_HEAD_INITIALIZER(tpm_drivers);
+
+TPMDriver *tpm_get_driver(const char *id)
+{
+TPMDriver *drv;
+QLIST_FOREACH(drv, tpm_drivers, list) {
+if (!strcmp(drv-id, id)) {
+return drv;
+}
+}
+return NULL;
+}
+
+
+typedef struct {
+const char *name;
+TPMDriver *(*open)(QemuOpts *opts);
+} TPMDriverTable;
+
+static const TPMDriverTable driver_table[] = {
+};
+
+int qemu_tpm_add(QemuOpts *opts) {
+TPMDriver *drv = NULL;
+int i;
+
+if (qemu_opts_id(opts) == NULL) {
+fprintf(stderr, tpm: no id specified\n);
+return -1;
+}
+
+for (i = 0; i  ARRAY_SIZE(driver_table); i++) {
+if (strcmp(driver_table[i].name, qemu_opt_get(opts, type)) == 0) {
+break;
+}
+}
+
+if (i == ARRAY_SIZE(driver_table)) {
+fprintf(stderr, tpm: backend type %s not found\n,
+qemu_opt_get(opts, type));
+return -1;
+}
+
+drv = driver_table[i].open(opts);
+
+if (drv == NULL) {
+return -1;
+}
+
+drv-id = qemu_strdup(qemu_opts_id(opts));
+
+QLIST_INSERT_HEAD(tpm_drivers, drv, list);
+
+return 0;
+}
diff --git a/hw/tpm_int.h b/hw/tpm_int.h
new file mode 100644
index 000..7869a81
--- /dev/null
+++ b/hw/tpm_int.h
@@ -0,0 +1,53 @@
+/*
+ * tpm_int.h - Internal header file for TPM device emulation
+ *
+ * Copyright (C) 2011 IAIK, Graz University of Technology
+ *
+ * Author: Andreas Niederl andreas.nied...@iaik.tugraz.at
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+
+#ifndef TPM_INT_H
+#define TPM_INT_H
+
+
+#include inttypes.h
+#include qemu-queue.h
+#include qemu-option.h
+
+
+typedef struct TPMDriver TPMDriver;
+struct TPMDriver {
+char *id;
+
+uint8_t  locty;
+uint8_t *buf;
+
+int (*send)(TPMDriver *drv, uint8_t locty, uint32_t len);
+int (*recv)(TPMDriver *drv, uint8_t locty, uint32_t len);
+
+QLIST_ENTRY(TPMDriver) list;
+};
+
+TPMDriver *tpm_get_driver(const char *id);
+
+#define TPM_MAX_PKT4096
+#define TPM_MAX_PATH   4096
+
+/*#define DEBUG_TPM*/
+#ifdef DEBUG_TPM
+void show_buff(unsigned char *buff, const char *string);
+#define DPRINTF(fmt, ...) \
+fprintf(stderr, tpm_tis: %s:  fmt, __FUNCTION__, ##__VA_ARGS__)
+#define DSHOW_BUFF(buf, info) 

[Qemu-devel] Re: [PATCH] Use sigwait instead of sigwaitinfo.

[Jan Kiszka]

On 2011-02-18 14:17, Tristan Gingold wrote:
 Fix compilation failure on Darwin.
 
 Signed-off-by: Tristan Gingold ging...@adacore.com
 ---
  compatfd.c |   36 ++--
  1 files changed, 18 insertions(+), 18 deletions(-)
 
 diff --git a/compatfd.c b/compatfd.c
 index a7cebc4..bd377c4 100644
 --- a/compatfd.c
 +++ b/compatfd.c
 @@ -26,45 +26,45 @@ struct sigfd_compat_info
  static void *sigwait_compat(void *opaque)
  {
  struct sigfd_compat_info *info = opaque;
 -int err;
  sigset_t all;
  
  sigfillset(all);
  sigprocmask(SIG_BLOCK, all, NULL);
  
 -do {
 -siginfo_t siginfo;
 +while (1) {
 +int sig;
 +int err;
  
 -err = sigwaitinfo(info-mask, siginfo);
 -if (err == -1  errno == EINTR) {
 -err = 0;
 -continue;
 -}
 -
 -if (err  0) {
 -char buffer[128];
 +err = sigwait(info-mask, sig);
 +if (err != 0) {
 +if (errno == EINTR) {
 +continue;
 +} else {
 +return NULL;
 +}
 +} else {
 +struct qemu_signalfd_siginfo buffer;
  size_t offset = 0;
  
 -memcpy(buffer, err, sizeof(err));
 +memset(buffer, 0, sizeof(buffer));
 +buffer.ssi_signo = sig;
 +
  while (offset  sizeof(buffer)) {
  ssize_t len;
  
 -len = write(info-fd, buffer + offset,
 +len = write(info-fd, (char *)buffer + offset,
  sizeof(buffer) - offset);
  if (len == -1  errno == EINTR)
  continue;
  
  if (len = 0) {
 -err = -1;
 -break;
 +return NULL;

This and the above handling of sigwait return codes changes the error
handling strategy. So far we silently skipped errors, now we silently
terminate the compatfd thread. I think none of both approaches is good.

Failing sigwait is likely a reason to bail out, but loudly, writing some
error message to the console and triggering a shutdown of qemu.

An overflow of the compatfd pipe to the main thread may be due to some
very unfortunate overload scenario. Not sure if that qualifies for a
thread termination (definitely not for a silent one).

Error handling should probably be adjusted independently of this darwin
build fix.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] [PATCH 4/5] Add configure script and command line options for TPM interface.

[Andreas Niederl]

Signed-off-by: Andreas Niederl andreas.nied...@iaik.tugraz.at
---
 configure   |9 +
 qemu-config.c   |   16 
 qemu-config.h   |1 +
 qemu-options.hx |6 ++
 vl.c|   22 ++
 5 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index a3f5345..7addec3 100755
--- a/configure
+++ b/configure
@@ -316,6 +316,7 @@ case $cpu in
   ;;
 esac
 
+tpm=no
 # OS specific
 if check_define __linux__ ; then
   targetos=Linux
@@ -455,6 +456,7 @@ Haiku)
   usb=linux
   if [ $cpu = i386 -o $cpu = x86_64 ] ; then
 audio_possible_drivers=$audio_possible_drivers fmod
+tpm=yes
   fi
 ;;
 esac
@@ -713,6 +715,8 @@ for opt do
   ;;
   --enable-vhost-net) vhost_net=yes
   ;;
+  --disable-tpm) tpm=no
+  ;;
   --*dir)
   ;;
   --disable-rbd) rbd=no
@@ -914,6 +918,7 @@ echoDefault:trace-pid
 echo   --disable-spice  disable spice
 echo   --enable-spice   enable spice
 echo   --enable-rbd enable building the rados block device (rbd)
+echo   --disable-tpmdisable tpm passthrough device emulation
 echo 
 echo NOTE: The object files are built at the place where configure is 
launched
 exit 1
@@ -2478,6 +2483,7 @@ echo Trace output file $trace_file-pid
 echo spice support $spice
 echo rbd support   $rbd
 echo xfsctl support$xfs
+echo tpm support   $tpm
 
 if test $sdl_too_old = yes; then
 echo - Your SDL version is too old - please upgrade to have SDL support
@@ -2739,6 +2745,9 @@ fi
 if test $fdatasync = yes ; then
   echo CONFIG_FDATASYNC=y  $config_host_mak
 fi
+if test $tpm = yes ; then
+  echo CONFIG_TPM=y  $config_host_mak
+fi
 if test $madvise = yes ; then
   echo CONFIG_MADVISE=y  $config_host_mak
 fi
diff --git a/qemu-config.c b/qemu-config.c
index 323d3c2..fe3a2ae 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -451,6 +451,22 @@ QemuOptsList qemu_option_rom_opts = {
 },
 };
 
+QemuOptsList qemu_tpm_opts = {
+.name = tpm,
+.implied_opt_name = type,
+.head = QTAILQ_HEAD_INITIALIZER(qemu_tpm_opts.head),
+.desc = {
+{
+.name = type,
+.type = QEMU_OPT_STRING,
+},{
+.name = path,
+.type = QEMU_OPT_STRING,
+},
+{ /*End of list */ }
+},
+};
+
 static QemuOptsList *vm_config_groups[32] = {
 qemu_drive_opts,
 qemu_chardev_opts,
diff --git a/qemu-config.h b/qemu-config.h
index 20d707f..eed9b3f 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -4,6 +4,7 @@
 extern QemuOptsList qemu_fsdev_opts;
 extern QemuOptsList qemu_virtfs_opts;
 extern QemuOptsList qemu_spice_opts;
+extern QemuOptsList qemu_tpm_opts;
 
 QemuOptsList *qemu_find_opts(const char *group);
 void qemu_add_opts(QemuOptsList *list);
diff --git a/qemu-options.hx b/qemu-options.hx
index 945edf3..cf4494d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2339,6 +2339,12 @@ STEXI
 Specify a trace file to log output traces to.
 ETEXI
 #endif
+#ifdef CONFIG_TPM
+DEF(tpm, HAS_ARG, QEMU_OPTION_tpm,
+-tpm host,id=id,path=path\n
+enable TPM support and forward commands to the given TPM 
device file\n,
+QEMU_ARCH_I386)
+#endif
 
 HXCOMM This is the last statement. Insert new options before this line!
 STEXI
diff --git a/vl.c b/vl.c
index f74f37a..4bafcce 100644
--- a/vl.c
+++ b/vl.c
@@ -1651,6 +1651,14 @@ static int fsdev_init_func(QemuOpts *opts, void *opaque)
 #endif
 
 #ifdef CONFIG_TPM
+static int tpm_init_func(QemuOpts *opts, void *opaque)
+{
+int ret;
+ret = qemu_tpm_add(opts);
+
+return ret;
+}
+
 static int tpm_acpi_init_func(QemuOpts *opts, void *opaque)
 {
 int ret = 0;
@@ -1993,6 +2001,10 @@ int main(int argc, char **argv, char **envp)
 tb_size = 0;
 autostart= 1;
 
+#ifdef CONFIG_TPM
+qemu_add_opts(qemu_tpm_opts);
+#endif
+
 /* first pass of option parsing */
 optind = 1;
 while (optind  argc) {
@@ -2493,6 +2505,13 @@ int main(int argc, char **argv, char **envp)
 qemu_free(arg_9p);
 break;
 }
+case QEMU_OPTION_tpm:
+   opts = qemu_opts_parse(qemu_find_opts(tpm), optarg, 0);
+   if (!opts) {
+   fprintf(stderr, parse error: %s\n, optarg);
+   exit(1);
+   }
+   break;
 case QEMU_OPTION_serial:
 add_device_config(DEV_SERIAL, optarg);
 default_serial = 0;
@@ -2881,6 +2900,9 @@ int main(int argc, char **argv, char **envp)
 #endif
 
 #ifdef CONFIG_TPM
+if (qemu_opts_foreach(qemu_find_opts(tpm), tpm_init_func, NULL, 1) != 0) 
{
+exit(1);
+}
 /* register TPM acpi table before machine-init is called */
 if (qemu_opts_foreach(qemu_find_opts(device), tpm_acpi_init_func, NULL, 
1) != 0) {
 exit(1);
-- 
1.7.4.1

[Qemu-devel] [PATCH] target-arm: return the right exit code when using semi-hosting.

[Christophe Lyon]

On ARM, the SYS_EXIT semi-hosting call has no room for application
exit code, hence exiting a program from qemu always returns 0.

This patch catches to argument passed to exit() and uses it as the
return code when processing SYS_EXIT.

Signed-off-by: Christophe Lyon christophe.l...@st.com
---
 arm-semi.c   |6 --
 cpu-exec.c   |   23 +++
 hw/elf_ops.h |   13 +
 hw/loader.c  |2 ++
 linux-user/elfload.c |   20 
 5 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/arm-semi.c b/arm-semi.c
index 1d5179b..4ef3769 100644
--- a/arm-semi.c
+++ b/arm-semi.c
@@ -166,6 +166,8 @@ static void arm_semi_flen_cb(CPUState *env, target_ulong 
ret, target_ulong err)
 #endif
 }
 
+extern target_ulong arm_exit_code;
+
 #define ARG(n) \
 ({ \
 target_ulong __arg;\
@@ -478,8 +480,8 @@ uint32_t do_arm_semihosting(CPUState *env)
 return 0;
 }
 case SYS_EXIT:
-gdb_exit(env, 0);
-exit(0);
+gdb_exit(env, arm_exit_code);
+exit(arm_exit_code);
 default:
 fprintf(stderr, qemu: Unsupported SemiHosting SWI 0x%02x\n, nr);
 cpu_dump_state(env, stderr, fprintf, 0);
diff --git a/cpu-exec.c b/cpu-exec.c
index b03b3a7..e1eac64 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -198,6 +198,14 @@ static inline TranslationBlock *tb_find_fast(void)
 
 /* main execution loop */
 
+/* On ARM, semi-hosting has no room for application exit code. To work
+   around this, when we start executing exit(), we take note of its
+   parameter, which will be used as return code.  */
+target_ulong addr_of_exit = 0;
+#if defined(TARGET_ARM)
+target_ulong arm_exit_code = 0;
+#endif
+
 volatile sig_atomic_t exit_request;
 
 int cpu_exec(CPUState *env1)
@@ -208,6 +216,10 @@ int cpu_exec(CPUState *env1)
 uint8_t *tc_ptr;
 unsigned long next_tb;
 
+#if defined(TARGET_ARM)
+static int arm_exit_reached = 0;
+#endif
+
 if (cpu_halted(env1) == EXCP_HALTED)
 return EXCP_HALTED;
 
@@ -544,6 +556,17 @@ int cpu_exec(CPUState *env1)
 #endif /* DEBUG_DISAS || CONFIG_DEBUG_EXEC */
 spin_lock(tb_lock);
 tb = tb_find_fast();
+
+#if defined(TARGET_ARM)
+/* When we reach exit(), make a copy of the
+   application exit code.  */
+if ((tb-pc == addr_of_exit)
+ (arm_exit_reached == 0)) {
+arm_exit_code = env-regs[0];
+arm_exit_reached = 1;
+}
+#endif
+
 /* Note: we do it here to avoid a gcc bug on Mac OS X when
doing it in tb_find_slow */
 if (tb_invalidated_flag) {
diff --git a/hw/elf_ops.h b/hw/elf_ops.h
index 0bd7235..373c8cd 100644
--- a/hw/elf_ops.h
+++ b/hw/elf_ops.h
@@ -181,6 +181,19 @@ static int glue(load_symbols, SZ)(struct elfhdr *ehdr, int 
fd, int must_swab,
 s-next = syminfos;
 syminfos = s;
 qemu_free(shdr_table);
+
+/* Take note of the address of the exit() function, to speed up
+   exit() calls tracking. This is currently used only for ARM, but
+   target-dependent code is not allowed in this module.  */
+i = 0;
+while (i  nsyms) {
+if (strcmp(exit, s-disas_strtab + syms[i].st_name) == 0) {
+addr_of_exit = syms[i].st_value;
+break;
+}
+i++;
+}
+
 return 0;
  fail:
 qemu_free(syms);
diff --git a/hw/loader.c b/hw/loader.c
index 35d792e..3ee9986 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -249,6 +249,8 @@ static void *load_at(int fd, int offset, int size)
 #define ELF_CLASS   ELFCLASS32
 #include elf.h
 
+extern int addr_of_exit;
+
 #define SZ 32
 #define elf_worduint32_t
 #define elf_swordint32_t
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 2de83e4..fa460c8 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1455,9 +1455,14 @@ static void load_elf_image(const char *image_name, int 
image_fd,
 info-brk = info-end_code;
 }
 
+#if !defined(TARGET_ARM)
+/* On ARM, we want symbols in order to catch exit() calls.  */
 if (qemu_log_enabled()) {
+#endif
 load_symbols(ehdr, image_fd, load_bias);
+#if !defined(TARGET_ARM)
 }
+#endif
 
 close(image_fd);
 return;
@@ -1545,6 +1550,8 @@ static int symcmp(const void *s0, const void *s1)
 : ((sym0-st_value  sym1-st_value) ? 1 : 0);
 }
 
+extern target_ulong addr_of_exit;
+
 /* Best attempt to load symbols from this ELF object. */
 static void load_symbols(struct elfhdr *hdr, int fd, abi_ulong load_bias)
 {
@@ -1641,6 +1648,19 @@ static void load_symbols(struct elfhdr *hdr, int fd, 
abi_ulong load_bias)
 s-lookup_symbol = lookup_symbolxx;
 s-next = syminfos;
 syminfos = s;
+
+/* Take note of the address of the 

[Qemu-devel] Re: [PATCH] Use sigwait instead of sigwaitinfo.

[Tristan Gingold]

On Feb 18, 2011, at 4:34 PM, Jan Kiszka wrote:
 
 This and the above handling of sigwait return codes changes the error
 handling strategy.

Did it ?  I don't think so.

 So far we silently skipped errors, now we silently
 terminate the compatfd thread. I think none of both approaches is good.

I think that both silently terminate the compatfd.  The previous code is:

  do {
siginfo_t siginfo;

err = sigwaitinfo(info-mask, siginfo);
if (err == -1  errno == EINTR) {
err = 0;
continue;
}

if (err  0) {
char buffer[128];
size_t offset = 0;

memcpy(buffer, err, sizeof(err));
while (offset  sizeof(buffer)) {
ssize_t len;

len = write(info-fd, buffer + offset,
sizeof(buffer) - offset);
if (len == -1  errno == EINTR)
continue;

if (len = 0) {
err = -1;
break;
}

offset += len;
}
}
} while (err = 0);

So in case of any error, err is set to a negative value which exits the thread.

 Failing sigwait is likely a reason to bail out, but loudly, writing some
 error message to the console and triggering a shutdown of qemu.

I agree with that.

 An overflow of the compatfd pipe to the main thread may be due to some
 very unfortunate overload scenario. Not sure if that qualifies for a
 thread termination (definitely not for a silent one).

What do you mean by overflow ?  Unless I am wrong, the fd is not non-blocking, 
write will block.

 Error handling should probably be adjusted independently of this darwin
 build fix.

I agree too.

Tristan.

[Qemu-devel] [PATCH 5/5] Adapt TPM host backend to use threadlets

[Andreas Niederl]

Signed-off-by: Andreas Niederl andreas.nied...@iaik.tugraz.at
---
 Makefile.objs |3 -
 hw/tpm_host_backend.c |  111 ++---
 2 files changed, 32 insertions(+), 82 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index 55fd6b5..5209a9b 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -285,9 +285,6 @@ hw-obj-$(CONFIG_VIRTFS) += virtio-9p-xattr-user.o 
virtio-9p-posix-acl.o
 
 # TPM passthrough device
 hw-obj-$(CONFIG_TPM) += tpm_tis.o tpm_backend.o tpm_host_backend.o
-ifndef CONFIG_THREAD
-common-obj-$(CONFIG_TPM) += qemu-thread.o
-endif
 
 ##
 # libdis
diff --git a/hw/tpm_host_backend.c b/hw/tpm_host_backend.c
index 4ae9deb..9204ede 100644
--- a/hw/tpm_host_backend.c
+++ b/hw/tpm_host_backend.c
@@ -20,17 +20,11 @@
 #include signal.h
 
 #include qemu-common.h
-#include qemu-thread.h
+#include qemu-threadlet.h
 
 #include hw/tpm_int.h
 
 
-typedef struct {
-QemuThread id;
-QemuMutex  lock;
-QemuCond   send_command;
-} TPMThread;
-
 #define STATUS_DONE(1  1)
 #define STATUS_IN_PROGRESS (1  0)
 #define STATUS_IDLE 0
@@ -38,7 +32,7 @@ typedef struct {
 typedef struct {
 TPMDriver common;
 
-TPMThread thread;
+ThreadletWork work;
 
 uint8_t   send_status;
 uint8_t   recv_status;
@@ -56,7 +50,6 @@ static int tpm_host_send(TPMDriver *drv, uint8_t locty, 
uint32_t len)
 
 drv-locty = locty;
 
-qemu_mutex_lock(hdrv-thread.lock);
 switch (hdrv-send_status) {
 case STATUS_IN_PROGRESS:
 break;
@@ -65,7 +58,7 @@ static int tpm_host_send(TPMDriver *drv, uint8_t locty, 
uint32_t len)
 hdrv-recv_len = TPM_MAX_PKT;
 /* asynchronous send */
 n = 1;
-qemu_cond_signal( hdrv-thread.send_command);
+submit_work(hdrv-work);
 break;
 case STATUS_DONE:
 n = hdrv-send_len;
@@ -78,7 +71,6 @@ static int tpm_host_send(TPMDriver *drv, uint8_t locty, 
uint32_t len)
 hdrv-send_status);
 break;
 }
-qemu_mutex_unlock(hdrv-thread.lock);
 
 return n;
 }
@@ -90,7 +82,6 @@ static int tpm_host_recv(TPMDriver *drv, uint8_t locty, 
uint32_t len)
 
 drv-locty = locty;
 
-qemu_mutex_lock(hdrv-thread.lock);
 switch (hdrv-recv_status) {
 case STATUS_IN_PROGRESS:
 break;
@@ -107,7 +98,6 @@ static int tpm_host_recv(TPMDriver *drv, uint8_t locty, 
uint32_t len)
 hdrv-recv_status);
 break;
 }
-qemu_mutex_unlock(hdrv-thread.lock);
 
 return n;
 }
@@ -153,82 +143,50 @@ static int unix_read(int fd, uint8_t *buf, uint32_t len)
 return len - len1;
 }
 
-static void die2(int err, const char *what)
-{
-fprintf(stderr, %s failed: %s\n, what, strerror(err));
-abort();
-}
-
-static void die(const char *what)
+static void tpm_host_send_receive(ThreadletWork *work)
 {
-die2(errno, what);
-}
-
-static void *tpm_host_thread(void *opaque)
-{
-TPMHostDriver *drv = opaque;
+TPMHostDriver *drv = container_of(work, TPMHostDriver, work);
 TPMDriver *s   = drv-common;
-sigset_t  set;
 uint32_t  tpm_ret;
 int ret;
 
-/* block all signals */
-if (sigfillset(set)) {
-die(sigfillset);
-}
-if (sigprocmask(SIG_BLOCK, set, NULL)) {
-die(sigprocmask);
-}
-
-qemu_mutex_lock(drv-thread.lock);
-while (1) {
-qemu_cond_wait(drv-thread.send_command, drv-thread.lock);
-drv-send_status = STATUS_IN_PROGRESS;
-qemu_mutex_unlock(drv-thread.lock);
+drv-send_status = STATUS_IN_PROGRESS;
 
-DSHOW_BUFF(s-buf, To TPM);
+DSHOW_BUFF(s-buf, To TPM);
 
-ret = unix_write(drv-fd, s-buf, drv-send_len);
+ret = unix_write(drv-fd, s-buf, drv-send_len);
 
-qemu_mutex_lock(drv-thread.lock);
-drv-send_len= ret;
-drv-send_status = STATUS_DONE;
+drv-send_len= ret;
+drv-send_status = STATUS_DONE;
 
-if (ret  0) {
-fprintf(stderr, Error: while transmitting data to host tpm
-: %s (%i)\n,
-strerror(errno), errno);
-continue;
-}
+if (ret  0) {
+  fprintf(stderr, Error: while transmitting data to host tpm
+  : %s (%i)\n,
+  strerror(errno), errno);
+}
 
-drv-recv_status = STATUS_IN_PROGRESS;
-qemu_mutex_unlock(drv-thread.lock);
+drv-recv_status = STATUS_IN_PROGRESS;
 
-ret = unix_read(drv-fd, s-buf, drv-recv_len);
+ret = unix_read(drv-fd, s-buf, drv-recv_len);
 
-qemu_mutex_lock(drv-thread.lock);
-drv-recv_len= ret;
-drv-recv_status = STATUS_DONE;
-drv-send_status = STATUS_IDLE;
+drv-recv_len= ret;
+drv-recv_status = STATUS_DONE;
+drv-send_status = STATUS_IDLE;
 
-if (ret  0) {
-fprintf(stderr, Error: while reading data 

[Qemu-devel] Re: [PATCH] Make spice dummy functions inline to fix calls not checking return values

[Gerd Hoffmann]

On 02/01/11 15:53, jes.soren...@redhat.com wrote:

From: Jes Sorensenjes.soren...@redhat.com

qemu_spice_set_passwd() and qemu_spice_set_pw_expire() dummy functions
needs to be inline, in order to handle the case where they are called
without checking the return value.


picked into spice patch queue.

thanks,
  Gerd

Re: [Qemu-devel] [PATCH] target-arm: return the right exit code when using semi-hosting.

[Peter Maydell]

On 18 February 2011 15:45, Christophe Lyon christophe.l...@st.com wrote:
 On ARM, the SYS_EXIT semi-hosting call has no room for application
 exit code, hence exiting a program from qemu always returns 0.

 This patch catches to argument passed to exit() and uses it as the
 return code when processing SYS_EXIT.

I'm afraid you've just run into the limitations of semihosting
as an API again: it doesn't provide a way for programs to pass
out an exit code, and trying to shoehorn back doors for this
into qemu just results in ugly code in qemu. The qemu
implementation of semihosting should implement the semihosting
API, not semihosting with weird undocumented extras.

If you care about this sort of thing then linux-user mode is
probably a better approach, as that is actually designed for
a unixish program to run as-if-natively.

-- PMM

[Qemu-devel] Re: [PATCH] Use sigwait instead of sigwaitinfo.

[Jan Kiszka]

On 2011-02-18 16:50, Tristan Gingold wrote:
 
 On Feb 18, 2011, at 4:34 PM, Jan Kiszka wrote:

 This and the above handling of sigwait return codes changes the error
 handling strategy.
 
 Did it ?  I don't think so.
 
 So far we silently skipped errors, now we silently
 terminate the compatfd thread. I think none of both approaches is good.
 
 I think that both silently terminate the compatfd.  The previous code is:
 
   do {
 siginfo_t siginfo;
 
 err = sigwaitinfo(info-mask, siginfo);
 if (err == -1  errno == EINTR) {
 err = 0;
 continue;
 }
 
 if (err  0) {
 char buffer[128];
 size_t offset = 0;
 
 memcpy(buffer, err, sizeof(err));
 while (offset  sizeof(buffer)) {
 ssize_t len;
 
 len = write(info-fd, buffer + offset,
 sizeof(buffer) - offset);
 if (len == -1  errno == EINTR)
 continue;
 
 if (len = 0) {
 err = -1;
 break;
 }
 
 offset += len;
 }
 }
 } while (err = 0);
 
 So in case of any error, err is set to a negative value which exits the 
 thread.

Ah, sorry, oversaw that. In that case the patch is fine as it does not
change the existing behavior.

 
 Failing sigwait is likely a reason to bail out, but loudly, writing some
 error message to the console and triggering a shutdown of qemu.
 
 I agree with that.
 
 An overflow of the compatfd pipe to the main thread may be due to some
 very unfortunate overload scenario. Not sure if that qualifies for a
 thread termination (definitely not for a silent one).
 
 What do you mean by overflow ?  Unless I am wrong, the fd is not 
 non-blocking, write will block.

True. So any error returned here is a real one.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH] target-arm: return the right exit code when using semi-hosting.

[Christophe Lyon]

On 18.02.2011 17:13, Peter Maydell wrote:
 
 I'm afraid you've just run into the limitations of semihosting
 as an API again: it doesn't provide a way for programs to pass
Indeed.

 out an exit code, and trying to shoehorn back doors for this
 into qemu just results in ugly code in qemu. The qemu
 implementation of semihosting should implement the semihosting
 API, not semihosting with weird undocumented extras.

Well, exit() is documented in the C ISO standard, so using its argument as exit 
code is doing what the user expects.
 
 If you care about this sort of thing then linux-user mode is
 probably a better approach, as that is actually designed for
 a unixish program to run as-if-natively.

We are using qemu to execute programs compiled in bare machine mode (eg with 
arm-none-eabi-gcc as opposed to arm-none-linux-gnueabi-gcc), where semihosting 
is used to communicate with the host environment. And we lack support for exit 
code.

Christophe.

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Anthony Liguori]

On 02/18/2011 09:22 AM, Gerd Hoffmann wrote:

  Hi,


It may not be so fundamental, but it still makes me wary. XMLRPC
handling is quite high level and introduces the potential of errors 
that

are outside of our direct control. Personally I don't see the big
benefit of having virtagent terminate in QEMU,


Live migration. If it's a separate daemon, then live migration gets 
fugly.


If xmlrpc-c is a PoS, then we ought to look at using something else.


Anyone looked at using json instead?  We already have a bunch of code 
for that thanks to QMP ...


It was really, really hard to reuse but with QAPI, it might be worth 
reconsidering.  But this is a fast moving area ATM.


Regards,

Anthony Liguori



cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/5] Add TPM 1.2 device interface

[Stefan Berger]

On 02/18/2011 10:33 AM, Andreas Niederl wrote:

This implementation is based on the TPM 1.2 interface for virtualized TPM
devices from the Xen-4.0.0 ioemu-qemu-xen fork.

A backend driver infrastructure is provided to be able to use different
device backends.

Signed-off-by: Andreas Niederlandreas.nied...@iaik.tugraz.at

--- /dev/null
+++ b/hw/tpm_tis.c
@@ -0,0 +1,705 @@
+/*
+ * tpm_tis.c - QEMU emulator for a 1.2 TPM with TIS interface
+ *
+ * Copyright (C) 2006 IBM Corporation
+ * Copyright (C) 2011 IAIK, Graz University of Technology
+ *
+ * Author: Stefan Bergerstef...@us.ibm.com
+ * David Saffordsaff...@us.ibm.com
+ *
+ * Author: Andreas Niederlandreas.nied...@iaik.tugraz.at
+ * Modified to use a separate TPM device backend
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ *
+ * Implementation of the TIS interface according to specs at
+ * https://www.trustedcomputinggroup.org/
+ *


I have a tpm_tis.c with major changes in it getting rid of the polling, 
closer to specs that passes a test suite and a registerable backend as 
well that has several more interface functions, due to support for 
snapshotting etc. Unfortunately it doesn't make much sense for me to 
post it since the backend is based on a library that's currently in the 
Fedora review process and nobody else could build or test it  -- unless 
there really was interest in reviewing at least some part of it.


It would certainly be desirable if your backend and mine could be 
accommodate.


Stefan

[Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD (v2)

[Paolo Bonzini]

On 02/17/2011 09:27 AM, Paolo Bonzini wrote:

It is -icount N which is broken and unfortunately your patch does not
fix it.


The problem is that for use_icount == 1 qemu_icount_delta always 
returns 0, and this makes no sense in the iothread case.  As soon as the 
delta becomes greater than 10 ms (the maximum adjustment in 
qemu_calculate_timeout) you just keep polling but hardly execute any code.


I'll try to post something in the weekend.

Paolo

Re: [Qemu-devel] [PATCH] target-arm: return the right exit code when using semi-hosting.

[Peter Maydell]

On 18 February 2011 16:29, Christophe Lyon christophe.l...@st.com wrote:
 We are using qemu to execute programs compiled in bare machine mode
 (eg with arm-none-eabi-gcc as opposed to arm-none-linux-gnueabi-gcc),
 where semihosting is used to communicate with the host environment.
 And we lack support for exit code.

You need to argue for improvements to the semihosting API/ABI
via whatever ARM support channels, I'm afraid.

-- PMM

Re: [Qemu-devel] [PATCH 1/5] Add TPM 1.2 device interface

[Andreas Niederl]

On 02/18/2011 05:37 PM, Stefan Berger wrote:
 On 02/18/2011 10:33 AM, Andreas Niederl wrote:
 This implementation is based on the TPM 1.2 interface for virtualized TPM
 devices from the Xen-4.0.0 ioemu-qemu-xen fork.

 A backend driver infrastructure is provided to be able to use different
 device backends.
[...]
 
 I have a tpm_tis.c with major changes in it getting rid of the polling,
 closer to specs that passes a test suite and a registerable backend as
 well that has several more interface functions, due to support for
 snapshotting etc. Unfortunately it doesn't make much sense for me to
 post it since the backend is based on a library that's currently in the
 Fedora review process and nobody else could build or test it  -- unless
 there really was interest in reviewing at least some part of it.

So I'm guessing that this library is not publicly available right now?

Is this backend meant for integration into QEMU or does it run as
separate process?

How/Where could I integrate a passthrough backend like the one in this
patch series?


The polling code isn't really necessary for the host backend, I left it
there just in case it would be needed by such a socket interface as is
used in the Xen fork.


 It would certainly be desirable if your backend and mine could be
 accommodate.

Of course.


Regards,
Andreas



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Qemu-devel] Re: Strategic decision: COW format

[Stefan Weil]

Am 18.02.2011 10:57, schrieb Kevin Wolf:

Am 18.02.2011 10:12, schrieb Markus Armbruster:

Kevin Wolf kw...@redhat.com writes:


Yet another file format with yet another implementation is definitely
not what we need. We should probably take some of the ideas in FVD and
consider them for qcow3.


Got an assumption there: that the one COW format we need must be qcow3,
i.e. an evolution of qcow2. Needs to be justified. If that discussion
has happened on the list already, I missed it. If not, it's overdue,
and then we better start it right away.


Right. I probably wasn't very clear about what I mean with qcow3 either,
so let me try to summarize my reasoning.


The first point is an assumption that you made, too: That we want to
have only one format. I hope it's easy to agree on this, duplication is
bad and every additional format creates new maintenance burden,
especially if we're taking it serious. Until now, there were exactly two
formats for which we managed to do this, raw and qcow2. raw is more or
less for free, so with the introduction of another format, we basically
double the supported block driver code overnight (while not doubling the
number of developers).

The consequence of having only one file format is that it must be able
to obsolete the existing ones, most notably qcow2. We can only neglect
qcow1 today because we can tell users to use qcow2. It supports
everything that qcow1 supports and more. We couldn't have done this if
qcow2 lacked features compared to qcow1.

So the one really essential requirement that I see is that we provide a
way forward for _all_ users by maintaining all of qcow2's features. This
is the only way of getting people to not stay with qcow2.



The support of several different file formats is one of the
strong points of QEMU, at least in my opinion.

Reducing this to offline conversion would be a bad idea because it costs
too much time and disk space for quick tests (for production environments,
this might be totally different).

Is maintaining an additional file format really so much work?
I have only some personal experience with vdi.c, and there maintainance
was largely caused by interface changes and done by Kevin.
Hopefully interfaces will stabilize, so changes will become less frequent.

A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!

Maybe adding a staging tree (like for the linux kernel) for experimental
drivers, devices, file formats, tcg targets and so on would make it easier
to add new code and reduce the need for QEMU forks. I'd appreciate such
or any other solution which allows this very much!

Regards,
Stefan

[Qemu-devel] Re: [PATCH 06/10] vmmouse: convert to qdev

[Blue Swirl]

On Fri, Feb 18, 2011 at 2:34 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 On 02/17/2011 08:52 PM, Blue Swirl wrote:

 On Wed, Feb 16, 2011 at 11:51 AM, Markus Armbrusterarm...@redhat.com
  wrote:

 Blue Swirlblauwir...@gmail.com  writes:

 On Tue, Feb 15, 2011 at 12:07 PM, Markus Armbrusterarm...@redhat.com
  wrote:

 Anthony Liguorianth...@codemonkey.ws  writes:

 On 02/12/2011 11:03 AM, Markus Armbruster wrote:

 Blue Swirlblauwir...@gmail.com    writes:


 Convert to qdev, also add a proper reset function.

 [...]

 Pointer properties are for dirty hacks only.  Is there really no
 better
 solution?  Why does it have to be a property?


 vmmouse is really just an extension to the PS2 Mouse.  It's definitely
 not an ISA device.

 In terms of qdev enablement, I would just make it a boolean option to
 the PS2Mouse and not expose it as a top level device at all.  It
 cannot exist without a PS2Mouse.

 Which means making it a separate qdev is wrong.  That wrongness gave
 rise to the dirty pointer property.  Pointer property serves as canary
 again.

 What now?

 I don't find pointer property use so dirty,

 See commit 036f7166.

                                             but I'll try to combine
 the devices to see whether that makes sense.

 Appreciated.

 The attached patch would merge the devices, but I'm not so sure this
 is the right approach. Merging seems to be OK, the registration could
 be removed harder by adding a switch for known vmport values.

 But vmmouse couldn't be left out of the build anymore since it would
 be built per target (because of CPUState dependencies). That would be
 a step backwards. Perhaps the register access helpers should be pushed
 to board level.

 Is there any fundamental reason why obj-i386-$(CONFIG_VMMOUSE) doesn't work?

Hm, actually nothing. There just aren't such devices except fulong
ones. I'll make a new patch.

Re: [Qemu-devel] [RFC PATCH] block: Fix eject -f for locked devices

[Blue Swirl]

On Fri, Feb 18, 2011 at 5:16 PM, Markus Armbruster arm...@redhat.com wrote:
 From 8cd4978c9be6ff2bcc414bb1c1b258b96b9a74c1 Mon Sep 17 00:00:00 2001
 From: Markus Armbruster arm...@redhat.com
 Date: Fri, 18 Feb 2011 15:54:02 +0100

 After forcefully ejecting media locked by the guest, you can't ever
 again insert new media.

 Example:

    (qemu) info block
    hda: type=hd removable=0 file=test.img ro=0 drv=raw encrypted=0
    cd: type=cdrom removable=1 locked=1 file=x.iso ro=0 drv=raw encrypted=0
    (qemu) eject cd
    Device 'cd' is locked
    (qemu) eject -f cd
    (qemu) info block
    hda: type=hd removable=0 file=test.img ro=0 drv=raw encrypted=0
    cd: type=cdrom removable=1 locked=1 [not inserted]
    (qemu) change cd x.iso
    Device 'cd' is locked

 Signed-off-by: Markus Armbruster arm...@redhat.com
 ---
 I'm not entirely sure this is the appropriate fix, and that's why
 there's RFC in the subject.

 Both IDE and SCSI devices expose their drive's BlockDriverState member
 locked to the guest via mode sense.

 What does real hardware do when I force-eject media (typically by
 rummaging in that little hole with a paperclip)?  Does it actively
 notify the OS?  Does mode sense change?

No idea, but IIRC the drive is still usable after that, so locking the
drive does not look correct.

 A possible alternative fix is to make do_change_block() ignore
 bdrv_is_locked() when inserting media into an empty drive.

Then the meaning of locked would change, maybe eject_disabled would
then describe the state better.

Re: [Qemu-devel] [PATCH] Use sigwait instead of sigwaitinfo.

[Blue Swirl]

On Fri, Feb 18, 2011 at 3:17 PM, Tristan Gingold ging...@adacore.com wrote:
 Fix compilation failure on Darwin.

Also OpenBSD needs this patch.

Re: [Qemu-devel] [PATCH 2/5] Provide SSDT for enabled TPM device

[Stefan Berger]

On 02/18/2011 10:33 AM, Andreas Niederl wrote:

Signed-off-by: Andreas Niederlandreas.nied...@iaik.tugraz.at
---
  Makefile.target |3 +++
  hw/acpi.c   |   28 
  hw/pc.h |1 +
  hw/tpm.h|2 ++
  hw/tpm_acpi.c   |   40 
  hw/tpm_ssdt.dsl |   55 +++
  hw/tpm_ssdt.hex |   41 +
  hw/tpm_tis.c|1 +
  rules.mak   |7 ++-
  vl.c|   23 +++
  10 files changed, 200 insertions(+), 1 deletions(-)
  create mode 100644 hw/tpm_acpi.c
  create mode 100644 hw/tpm_ssdt.dsl
  create mode 100644 hw/tpm_ssdt.hex

diff --git a/Makefile.target b/Makefile.target
index 5a0fd40..33ffe19 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -211,6 +211,9 @@ obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
  # Inter-VM PCI shared memory
  obj-$(CONFIG_KVM) += ivshmem.o

+# TPM acpi support
+obj-$(CONFIG_TPM) += tpm_acpi.o
+
  # Hardware support
  obj-i386-y += vga.o
  obj-i386-y += mc146818rtc.o i8259.o pc.o
diff --git a/hw/acpi.c b/hw/acpi.c
index 8071e7b..93656c5 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -35,6 +35,34 @@ struct acpi_table_header
  char *acpi_tables;
  size_t acpi_tables_len;

+
+/*
+ * add a table directly (e.g. iasl C source output)
+ */
+int acpi_table_add_raw(const char *t, uint32_t length)
+{
+char *p;
+
+if (!acpi_tables) {
+acpi_tables_len = sizeof(uint16_t);
+acpi_tables = qemu_mallocz(acpi_tables_len);
+}
+acpi_tables = qemu_realloc(acpi_tables,
+   acpi_tables_len + sizeof(uint16_t) + length);
+p = acpi_tables + acpi_tables_len;
+acpi_tables_len += sizeof(uint16_t) + length;
+
+*(uint16_t*)p = cpu_to_le32(length);
+p += sizeof(uint16_t);
+
+memcpy(p, t, length);
+
+/* increase number of tables */
+(*(uint16_t*)acpi_tables) =
+cpu_to_le32(le32_to_cpu(*(uint16_t*)acpi_tables) + 1);
+return 0;
+}
+
Does it show up in Linux? I am trying to find the code that connects it 
to the RSDT, but don't see any.


Stefan

Re: [Qemu-devel] [ANNOUNCE] QEMU 0.14.0.tar.gz is available

[Miguel Di Ciurcio Filho]

On Thu, Feb 17, 2011 at 10:06 PM, Anthony Liguori anth...@codemonkey.ws wrote:
 The QEMU team is pleased to announce the availability of the 0.14.0 release.

 Download instructions are available at http://wiki.qemu.org/Download

 A detailed change log is available at http://wiki.qemu.org/Changelog/0.14


Great, although we ended up without information about i386/amd64/kvm
on the changelog. Maybe next time :-D

It would be nice to announce on freshmeat.net, or at least update the
project page there. It seams that the person who registered QEMU does
not care anymore. It is heavily outdated.

http://freshmeat.net/projects/qemu

I could try to reclaim the project to update that information or ping
the person who registered the project, if you and the other
maintainers are OK with it. Or someone else.

Regards,

Miguel

Re: [Qemu-devel] Re: Strategic decision: COW format

[Kevin Wolf]

Am 18.02.2011 18:43, schrieb Stefan Weil:
 Am 18.02.2011 10:57, schrieb Kevin Wolf:
 Am 18.02.2011 10:12, schrieb Markus Armbruster:
 Kevin Wolf kw...@redhat.com writes:

 Yet another file format with yet another implementation is definitely
 not what we need. We should probably take some of the ideas in FVD and
 consider them for qcow3.

 Got an assumption there: that the one COW format we need must be qcow3,
 i.e. an evolution of qcow2. Needs to be justified. If that discussion
 has happened on the list already, I missed it. If not, it's overdue,
 and then we better start it right away.

 Right. I probably wasn't very clear about what I mean with qcow3 either,
 so let me try to summarize my reasoning.


 The first point is an assumption that you made, too: That we want to
 have only one format. I hope it's easy to agree on this, duplication is
 bad and every additional format creates new maintenance burden,
 especially if we're taking it serious. Until now, there were exactly two
 formats for which we managed to do this, raw and qcow2. raw is more or
 less for free, so with the introduction of another format, we basically
 double the supported block driver code overnight (while not doubling the
 number of developers).

 The consequence of having only one file format is that it must be able
 to obsolete the existing ones, most notably qcow2. We can only neglect
 qcow1 today because we can tell users to use qcow2. It supports
 everything that qcow1 supports and more. We couldn't have done this if
 qcow2 lacked features compared to qcow1.

 So the one really essential requirement that I see is that we provide a
 way forward for _all_ users by maintaining all of qcow2's features. This
 is the only way of getting people to not stay with qcow2.
 
 
 The support of several different file formats is one of the
 strong points of QEMU, at least in my opinion.

I totally agree. qemu-img is known as a Swiss army knife for disk images
and this is definitely a strength.

However, it's not useful just because it supports a high number of
formats, but because these formats are in active use. Most of them are
the native formats of some other software.

I think things look a bit different when we're talking about
qemu-specific formats. qcow1 isn't in use any more because nobody needs
it for compatibility with other software and for use with qemu, there is
qcow2. Still, the qcow1 driver is still around and bitrots.

 Reducing this to offline conversion would be a bad idea because it costs
 too much time and disk space for quick tests (for production environments,
 this might be totally different).

Either I'm misunderstanding what you try to say here, or you
miunderstood what I said. I agree that we don't want to have to do
qemu-img convert (i.e. a full copy) in order to upgrade. This is one of
the reasons why I think we should have a qcow3 which can be upgraded
basically by increasing the version number in the header (look at it as
an incompatible feature flag, if you want) instead of starting something
completely new.

 Is maintaining an additional file format really so much work?
 I have only some personal experience with vdi.c, and there maintainance
 was largely caused by interface changes and done by Kevin.
 Hopefully interfaces will stabilize, so changes will become less frequent.

Well, there are different types of maintenance.

It's not much work to just drop the code into qemu and let it bitrot.
This is what happens to the funky formats like bochs or dmg. They are
usually patches enough so that they still build, but nobody tries if
they actually work.

Then there are formats in which there is at least some interest, like
vmdk or vdi. Occasionally they get some fixes, they are probably fine
for image conversion, but I wouldn't really trust them for production use.

And then there's raw and qcow2, which are used by a lot of people for
running VMs, that are actively maintained, get a decent level of review
and fixes etc. Getting a format into this group really takes a lot of
work. Taking something like FVD would only make sense if we are willing
to do that work - I mean, really nobody wants to convert from/to a file
format that isn't implemented anywhere else.

 A new file format like fvd would be a challenge for the existing ones.
 Declare its support as unsupported or experimental, but let users
 decide which one is best suited to their needs!

Basically this is what we did for QED. In hindsight I consider it a
mistake because it set a bad precedence of inventing something new
instead of fixing what's there. I really don't want to convert all my
images each time to take advantage of new qemu version.

Kevin

Re: [Qemu-devel] Re: Strategic decision: COW format

[Anthony Liguori]

On 02/18/2011 01:11 PM, Kevin Wolf wrote:

A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!
 

Basically this is what we did for QED. In hindsight I consider it a
mistake because it set a bad precedence of inventing something new
instead of fixing what's there.


I don't see how qcow3 is fixing something that's there since it's still 
an incompatible format.


It'd be a stronger argument if you were suggesting something that was 
still fully compatible with qcow2 but once compatibility is broken, it's 
broken.


Regards,

Anthony Liguori


  I really don't want to convert all my
images each time to take advantage of new qemu version.

Kevin

   

Re: [Qemu-devel] [PATCH 1/5] Add TPM 1.2 device interface

[Stefan Berger]

On 02/18/2011 12:37 PM, Andreas Niederl wrote:

On 02/18/2011 05:37 PM, Stefan Berger wrote:

On 02/18/2011 10:33 AM, Andreas Niederl wrote:

This implementation is based on the TPM 1.2 interface for virtualized TPM
devices from the Xen-4.0.0 ioemu-qemu-xen fork.

A backend driver infrastructure is provided to be able to use different
device backends.

[...]

I have a tpm_tis.c with major changes in it getting rid of the polling,
closer to specs that passes a test suite and a registerable backend as
well that has several more interface functions, due to support for
snapshotting etc. Unfortunately it doesn't make much sense for me to
post it since the backend is based on a library that's currently in the
Fedora review process and nobody else could build or test it  -- unless
there really was interest in reviewing at least some part of it.

So I'm guessing that this library is not publicly available right now?

Not via the fedora repository at least. So yum install does not work, yet.

Is this backend meant for integration into QEMU or does it run as
separate process?


The backend is meant for integration in Qemu. It runs as a thread.

How/Where could I integrate a passthrough backend like the one in this
patch series?

It's possible via similar mechanisms as you have, just the interface is 
bigger and main code calls into the interface at different times. I'd 
need to share the code with you.

The polling code isn't really necessary for the host backend, I left it
there just in case it would be needed by such a socket interface as is
used in the Xen fork.

I don't think it's necessary to have it all. In the new code, the  
frontend delivers a request to the backend and provides a callback 
function for delivering the response back once received.



It would certainly be desirable if your backend and mine could be
accommodate.

Of course.


Let's see how we do this.

  Stefan


Regards,
Andreas

Re: [Qemu-devel] Re: Strategic decision: COW format

[Anthony Liguori]

On 02/18/2011 11:43 AM, Stefan Weil wrote:


Is maintaining an additional file format really so much work?
I have only some personal experience with vdi.c, and there maintainance
was largely caused by interface changes and done by Kevin.
Hopefully interfaces will stabilize, so changes will become less 
frequent.


A new file format like fvd would be a challenge for the existing ones.


FVD isn't merged because it's gotten almost no review.  If it turns out 
that it is identical to an existing format and an existing format just 
has a crappy implementation, it wouldn't be merged in favor of fixing 
the existing format.


But if it has a compelling advantage for a reasonable use-case, it will 
be merged.


I don't know where this whole discussion of strategic formats for QEMU 
came from but that's never been the way the project has operated.


Regards,

Anthony Liguori

[Qemu-devel] [PATCH] Merge vmmouse and vmport

[Blue Swirl]

Fix also a typo in default-configs/x86_64-softmmu.

Signed-off-by: Blue Swirl blauwir...@gmail.com
---
 Makefile.objs  |1 -
 Makefile.target|3 +-
 default-configs/x86_64-softmmu.mak |2 +-
 hw/pc.c|1 -
 hw/pc.h|9 --
 hw/vmmouse.c   |  129 ---
 hw/vmport.c|  149 
 7 files changed, 120 insertions(+), 174 deletions(-)
 delete mode 100644 hw/vmport.c

diff --git a/Makefile.objs b/Makefile.objs
index b21f9d3..a6f8b31 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -259,7 +259,6 @@ hw-obj-$(CONFIG_VGA_PCI) += vga-pci.o
 hw-obj-$(CONFIG_VGA_ISA) += vga-isa.o
 hw-obj-$(CONFIG_VGA_ISA_MM) += vga-isa-mm.o
 hw-obj-$(CONFIG_VMWARE_VGA) += vmware_vga.o
-hw-obj-$(CONFIG_VMMOUSE) += vmmouse.o

 hw-obj-$(CONFIG_RC4030) += rc4030.o
 hw-obj-$(CONFIG_DP8393X) += dp8393x.o
diff --git a/Makefile.target b/Makefile.target
index 5a0fd40..5f8cf27 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -215,7 +215,8 @@ obj-$(CONFIG_KVM) += ivshmem.o
 obj-i386-y += vga.o
 obj-i386-y += mc146818rtc.o i8259.o pc.o
 obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
-obj-i386-y += vmport.o applesmc.o
+obj-i386-y += applesmc.o
+obj-i386-$(CONFIG_VMMOUSE) += vmmouse.o
 obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
 obj-i386-y += debugcon.o multiboot.o
 obj-i386-y += pc_piix.o kvmclock.o
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 1cc1b61..9192d47 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -4,7 +4,7 @@ include pci.mak
 CONFIG_VGA_PCI=y
 CONFIG_VGA_ISA=y
 CONFIG_VMWARE_VGA=y
-CONFIG_VMMMOUSE=y
+CONFIG_VMMOUSE=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
 CONFIG_I8254=y
diff --git a/hw/pc.c b/hw/pc.c
index 56bf1d6..fe0afb9 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1136,7 +1136,6 @@ void pc_basic_device_init(qemu_irq *isa_irq,
 a20_line = qemu_allocate_irqs(handle_a20_line_change, first_cpu, 2);
 i8042 = isa_create_simple(i8042);
 i8042_setup_a20_line(i8042, a20_line[0]);
-vmport_init();
 vmmouse = isa_try_create(vmmouse);
 if (vmmouse) {
 qdev_prop_set_ptr(vmmouse-qdev, ps2_mouse, i8042);
diff --git a/hw/pc.h b/hw/pc.h
index d5d2f42..4537c9c 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -64,15 +64,6 @@ int pit_get_out(PITState *pit, int channel, int64_t
current_time);
 void hpet_pit_disable(void);
 void hpet_pit_enable(void);

-/* vmport.c */
-static inline void vmport_init(void)
-{
-isa_create_simple(vmport);
-}
-void vmport_register(unsigned char command, IOPortReadFunc *func,
void *opaque);
-void vmmouse_get_data(uint32_t *data);
-void vmmouse_set_data(const uint32_t *data);
-
 /* pckbd.c */

 void i8042_init(qemu_irq kbd_irq, qemu_irq mouse_irq, uint32_t io_base);
diff --git a/hw/vmmouse.c b/hw/vmmouse.c
index ab8dbd6..19a4dfc 100644
--- a/hw/vmmouse.c
+++ b/hw/vmmouse.c
@@ -2,6 +2,7 @@
  * QEMU VMMouse emulation
  *
  * Copyright (C) 2007 Anthony Liguori anth...@codemonkey.ws
+ * Copyright (C) 2007 HervĂŠ Poussineau
  *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the
Software), to deal
@@ -26,10 +27,21 @@
 #include ps2.h
 #include pc.h
 #include qdev.h
+#include isa.h
+#include sysemu.h
+#include kvm.h

 /* debug only vmmouse */
 //#define DEBUG_VMMOUSE

+//#define VMPORT_DEBUG
+
+#ifdef DEBUG_VMMOUSE
+#define DPRINTF(fmt, ...) printf(fmt, ## __VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...) do { } while (0)
+#endif
+
 /* VMMouse Commands */
 #define VMMOUSE_GETVERSION 10
 #define VMMOUSE_DATA   39
@@ -45,11 +57,12 @@

 #define VMMOUSE_VERSION0x3442554a

-#ifdef DEBUG_VMMOUSE
-#define DPRINTF(fmt, ...) printf(fmt, ## __VA_ARGS__)
-#else
-#define DPRINTF(fmt, ...) do { } while (0)
-#endif
+/* VMPort Commands */
+#define VMPORT_CMD_GETVERSION 0x0a
+#define VMPORT_CMD_GETRAMSIZE 0x14
+
+#define VMPORT_ENTRIES 0x2c
+#define VMPORT_MAGIC   0x564D5868

 typedef struct _VMMouseState
 {
@@ -63,6 +76,71 @@ typedef struct _VMMouseState
 void *ps2_mouse;
 } VMMouseState;

+typedef struct VMPortState {
+ISADevice dev;
+IOPortReadFunc *func[VMPORT_ENTRIES];
+void *opaque[VMPORT_ENTRIES];
+VMMouseState mouse;
+} VMPortState;
+
+static void vmport_register(VMPortState *s, unsigned char command,
+IOPortReadFunc *func)
+{
+assert(command  VMPORT_ENTRIES);
+
+s-func[command] = func;
+}
+
+static uint32_t vmport_ioport_read(void *opaque, uint32_t addr)
+{
+VMPortState *s = opaque;
+CPUState *env = cpu_single_env;
+unsigned char command;
+uint32_t eax;
+
+cpu_synchronize_state(env);
+
+eax = env-regs[R_EAX];
+if (eax != VMPORT_MAGIC) {
+return eax;
+}
+
+command = env-regs[R_ECX];
+

Re: [Qemu-devel] Re: Strategic decision: COW format

[Kevin Wolf]

Am 18.02.2011 20:47, schrieb Anthony Liguori:
 On 02/18/2011 01:11 PM, Kevin Wolf wrote:
 A new file format like fvd would be a challenge for the existing ones.
 Declare its support as unsupported or experimental, but let users
 decide which one is best suited to their needs!
  
 Basically this is what we did for QED. In hindsight I consider it a
 mistake because it set a bad precedence of inventing something new
 instead of fixing what's there.
 
 I don't see how qcow3 is fixing something that's there since it's still 
 an incompatible format.
 
 It'd be a stronger argument if you were suggesting something that was 
 still fully compatible with qcow2 but once compatibility is broken, it's 
 broken.

It's really more like adding an incompatible feature flag in QED. You
still have one implementation for old and new images instead of
splitting up development efforts, you still have all of the features and
so on. It's a completely different story than QED.

Kevin

Re: [Qemu-devel] Re: Strategic decision: COW format

[Anthony Liguori]

On 02/18/2011 02:49 PM, Kevin Wolf wrote:

Am 18.02.2011 20:47, schrieb Anthony Liguori:
   

On 02/18/2011 01:11 PM, Kevin Wolf wrote:
 

A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!

 

Basically this is what we did for QED. In hindsight I consider it a
mistake because it set a bad precedence of inventing something new
instead of fixing what's there.
   

I don't see how qcow3 is fixing something that's there since it's still
an incompatible format.

It'd be a stronger argument if you were suggesting something that was
still fully compatible with qcow2 but once compatibility is broken, it's
broken.
 

It's really more like adding an incompatible feature flag in QED. You
still have one implementation for old and new images instead of
splitting up development efforts, you still have all of the features and
so on.


In theory.  Since an implementation doesn't exist, we have no idea how 
much code is actually going to be shared at the end of the day.


I suspect that, especially if you drop the ref table updates, there 
won't be an awful lot of common code in the two paths.


Regards,

Anthony Liguori


  It's a completely different story than QED.

Kevin
   

Re: [Qemu-devel] [PATCH] Merge vmmouse and vmport

[Anthony Liguori]

On 02/18/2011 02:45 PM, Blue Swirl wrote:

Fix also a typo in default-configs/x86_64-softmmu.

Signed-off-by: Blue Swirlblauwir...@gmail.com
   


Since we never really implemented much of vmport, this seems reasonable 
to me.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 1/5] Add TPM 1.2 device interface

[Stefan Berger]

On 02/18/2011 10:33 AM, Andreas Niederl wrote:

+
+static const VMStateDescription vmstate_loc = {
+.name   = loc,
+.version_id = 0,
+.fields = (VMStateField []) {
+VMSTATE_UINT32(state, TPMLocality),
+VMSTATE_UINT32(inte,  TPMLocality),
+VMSTATE_UINT32(ints,  TPMLocality),
+VMSTATE_UINT8(access, TPMLocality),
+VMSTATE_UINT8(sts,TPMLocality),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_tpm = {
+.name   = tpm,
+.version_id = 0,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
+.pre_save   = tpm_pre_save,
+.fields = (VMStateField []) {
+VMSTATE_UINT32(irq,TPMState),
+VMSTATE_UINT32(offset, TPMState),
+VMSTATE_BUFFER(buf,TPMState),
+VMSTATE_UINT8(  active_locty, TPMState),
+VMSTATE_UINT8(aborting_locty, TPMState),
+VMSTATE_UINT8(next_locty, TPMState),
+VMSTATE_STRUCT_ARRAY(loc, TPMState, NUM_LOCALITIES, 0,
+ vmstate_loc, TPMLocality),

Here you are pointing to the above vmstate_loc ...

+VMSTATE_END_OF_LIST()
+}
+};
+
+/*



+
+vmstate_register(dev-qdev, 1,vmstate_tpm, s);
+for (i = 0; i  NUM_LOCALITIES; i++) {
+vmstate_register(dev-qdev, 1,vmstate_loc,s-loc[i]);

... here you are (again) registering the localities ...

+}
+
+isa_init_irq(dev,s-pic, isairq);
+s-irq = isairq;
+
+iomem = cpu_register_io_memory(tis_readfn, tis_writefn, s,
+DEVICE_LITTLE_ENDIAN);
+cpu_register_physical_memory(TIS_ADDR_BASE,
+0x1000 * NUM_LOCALITIES, iomem);
+
+s-poll_timer = qemu_new_timer(vm_clock, tis_poll_timer, s);
+
+return 0;
+}
+
+static void qdev_tpm_reset(DeviceState *dev)
+{
+TPMState *s = DO_UPCAST(TPMState, dev.qdev, dev);
+tpm_reset(s);
+}
+
+static ISADeviceInfo tpm_info = {
+.init  = tpm_init,
+.qdev.name = tpm,
+.qdev.desc = TPM TIS Interface,
+.qdev.size = sizeof (TPMState),
+.qdev.vmsd =vmstate_tpm,
... and here you're pointing to vmstate_tpm, which was also registered 
above using


+
+vmstate_register(dev-qdev, 1,vmstate_tpm, s);


Are you sure this is necessary? In my implementation I only have the 
qdev.vmsd set and need not explicitly use vmstate_register(). Aren't you 
writing the state two times if you do that?


   Stefan

Re: [Qemu-devel] Re: Strategic decision: COW format

[Kevin Wolf]

Am 18.02.2011 21:50, schrieb Anthony Liguori:
 On 02/18/2011 02:49 PM, Kevin Wolf wrote:
 Am 18.02.2011 20:47, schrieb Anthony Liguori:

 On 02/18/2011 01:11 PM, Kevin Wolf wrote:
  
 A new file format like fvd would be a challenge for the existing ones.
 Declare its support as unsupported or experimental, but let users
 decide which one is best suited to their needs!

  
 Basically this is what we did for QED. In hindsight I consider it a
 mistake because it set a bad precedence of inventing something new
 instead of fixing what's there.

 I don't see how qcow3 is fixing something that's there since it's still
 an incompatible format.

 It'd be a stronger argument if you were suggesting something that was
 still fully compatible with qcow2 but once compatibility is broken, it's
 broken.
  
 It's really more like adding an incompatible feature flag in QED. You
 still have one implementation for old and new images instead of
 splitting up development efforts, you still have all of the features and
 so on.
 
 In theory.  Since an implementation doesn't exist, we have no idea how 
 much code is actually going to be shared at the end of the day.
 
 I suspect that, especially if you drop the ref table updates, there 
 won't be an awful lot of common code in the two paths.

Allowing refcounts to be inconsistent, protected by a dirty flag, is
only an option, and you should only take it if you absolutely need it
(i.e. your guest is broken and requires cache=writethrough, but you
desperately need performance)

My preferred way of implementing it is telling the refcount cache that
it should ignore flushes and write its data only back when another
refcount block must be loaded into the cache (which happens rarely
enough that it doesn't really hurt performance). This makes the
difference from the existing code more or less one if statement that
returns early.

Kevin

Re: [Qemu-devel] MIPS dynamically linked ELF with Qemu

[Mulyadi Santosa]

On Fri, Feb 18, 2011 at 17:13, maheen butt maheen_but...@yahoo.com wrote:

 hi
 I want to run MIPS dynamically linked ELF in user mode emulation on x86 host 
 machine, what should I do?


I think you need to grab MIPS Linux root filesystem somewhere. IIRC,
I've seen MIPS disc image posted in qemu main website. Maybe you can
use that.


--
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

[Qemu-devel] [Bug 721659] [NEW] qemu-kvm-0.13.0 doesn't pass USB devices to the VM

[Arsen.Shnurkov]

Public bug reported:

I have the bug, similar to this one:
https://bugzilla.redhat.com/show_bug.cgi?id=583108
but under gentoo

When I add parameters -usb -usbdevice host:4348:5584, I see the
following lines in console:

husb: config #1 need -1
USBDEVFS_DISCONNECT: No route to host
husb: open device 2.11
(...many repetitions of three above lines...)

All parameters (2.11) are verified with lsusb at host computer -
parameters are correct

Error description is very confusing - I don't know what to check, what
config #1 mean, which route should be checked and how to check it.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721659

Title:
  qemu-kvm-0.13.0 doesn't pass USB devices to the VM

Status in QEMU:
  New

Bug description:
  I have the bug, similar to this one:
  https://bugzilla.redhat.com/show_bug.cgi?id=583108
  but under gentoo

  When I add parameters -usb -usbdevice host:4348:5584, I see the
  following lines in console:

  husb: config #1 need -1
  USBDEVFS_DISCONNECT: No route to host
  husb: open device 2.11
  (...many repetitions of three above lines...)

  All parameters (2.11) are verified with lsusb at host computer -
  parameters are correct

  Error description is very confusing - I don't know what to check, what
  config #1 mean, which route should be checked and how to check it.