date:20111229

On (Thu) 29 Dec 2011 [15:32:14], Christian Borntraeger wrote:
> > port->throttled never becomes true for qemu.  
> 
> Huh? What did I miss below?
> 
> if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> virtio_serial_throttle_port(port, true);

'ret' here is the return value from info->have_data(), which is
hw/virtio-console.c:flush_buf().  That function returns the value that
qemu_chr_fe_write() returns, which is qemu-char.c:send_all() for pty,
tcp, unix sockets.  send_all() just keeps spinning here if it can't
write, doesn't signal EAGAIN at all (or even a partial write).

Can you print out the return values of have_data to check what's going
on?  Maybe you're hitting a case I never hit earlier and throttling
indeed does get enabled?

Amit

Re: [Qemu-devel] [Seabios] [PATCH 0/3] 64bit PCI BARs allocations

On Thu, Dec 29, 2011 at 09:20:00AM +, Alexey Korolev wrote:
> >>
> > Patches have been tested on several configurations which includes
> >> linux 2.6.18 - 3.0 &
> >> windows 2008. Everything works quite well.
> 
> >Which qemu version did you use?
> I tried both 0.15 and 1.0
qemu or qemu-kcm?

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

> port->throttled never becomes true for qemu.  

Huh? What did I miss below?

if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
virtio_serial_throttle_port(port, true);
   |
   |
   V
void virtio_serial_throttle_port(VirtIOSerialPort *port, bool throttle)
{
if (!port) {
return;
}

trace_virtio_serial_throttle_port(port->id, throttle);
port->throttled = throttle;  < WHOOOT!
if (throttle) {
return;
}
qemu_bh_schedule(port->bh);
}

[Qemu-devel] [PATCH 01/11] linux-user: Add default-configs for mipsn32[el]

Prepares for mipsn32[el]-linux-user targets.

Signed-off-by: Ulricht Hecht 
Signed-off-by: Andreas Färber 
---
 default-configs/mipsn32-linux-user.mak   |1 +
 default-configs/mipsn32el-linux-user.mak |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 default-configs/mipsn32-linux-user.mak
 create mode 100644 default-configs/mipsn32el-linux-user.mak

diff --git a/default-configs/mipsn32-linux-user.mak 
b/default-configs/mipsn32-linux-user.mak
new file mode 100644
index 000..5b97919
--- /dev/null
+++ b/default-configs/mipsn32-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for mipsn32-linux-user
diff --git a/default-configs/mipsn32el-linux-user.mak 
b/default-configs/mipsn32el-linux-user.mak
new file mode 100644
index 000..d6367ff
--- /dev/null
+++ b/default-configs/mipsn32el-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for mipsn32el-linux-user
-- 
1.7.7

[Qemu-devel] [PATCH v5 2/7] arm: Set frequencies for arm_timer

Use qdev properties to allow board modelers to set the frequencies
for the sp804 timer. Each of the sp804's timers can have an
individual frequency. The timers default to 1MHz.

Signed-off-by: Mark Langsdorf 
Reviewed-by: Peter Maydell 
Reviewed-by: Andreas Färber 
---
Changes from v3, v4
None
Changes from v2
Comment correctly describes behavior of properties
freqX variables are defined as uint32_t, not int
Changes from v1
Simplified multiple timer frequency handling
Removed the shared default

 hw/arm_timer.c |   24 +++-
 1 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/hw/arm_timer.c b/hw/arm_timer.c
index 0a5b9d2..60e1c63 100644
--- a/hw/arm_timer.c
+++ b/hw/arm_timer.c
@@ -9,6 +9,8 @@
 
 #include "sysbus.h"
 #include "qemu-timer.h"
+#include "qemu-common.h"
+#include "qdev.h"
 
 /* Common timer implementation.  */
 
@@ -178,6 +180,7 @@ typedef struct {
 SysBusDevice busdev;
 MemoryRegion iomem;
 arm_timer_state *timer[2];
+uint32_t freq0, freq1;
 int level[2];
 qemu_irq irq;
 } sp804_state;
@@ -269,10 +272,11 @@ static int sp804_init(SysBusDevice *dev)
 
 qi = qemu_allocate_irqs(sp804_set_irq, s, 2);
 sysbus_init_irq(dev, &s->irq);
-/* ??? The timers are actually configurable between 32kHz and 1MHz, but
-   we don't implement that.  */
-s->timer[0] = arm_timer_init(100);
-s->timer[1] = arm_timer_init(100);
+/* The timers are configurable between 32kHz and 1MHz
+ * defaulting to 1MHz but overrideable as individual properties */
+s->timer[0] = arm_timer_init(s->freq0);
+s->timer[1] = arm_timer_init(s->freq1);
+
 s->timer[0]->irq = qi[0];
 s->timer[1]->irq = qi[1];
 memory_region_init_io(&s->iomem, &sp804_ops, s, "sp804", 0x1000);
@@ -281,6 +285,16 @@ static int sp804_init(SysBusDevice *dev)
 return 0;
 }
 
+static SysBusDeviceInfo sp804_info = {
+.init = sp804_init,
+.qdev.name = "sp804",
+.qdev.size = sizeof(sp804_state),
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT32("freq0", sp804_state, freq0, 100),
+DEFINE_PROP_UINT32("freq1", sp804_state, freq1, 100),
+DEFINE_PROP_END_OF_LIST(),
+}
+};
 
 /* Integrator/CP timer module.  */
 
@@ -349,7 +363,7 @@ static int icp_pit_init(SysBusDevice *dev)
 static void arm_timer_register_devices(void)
 {
 sysbus_register_dev("integrator_pit", sizeof(icp_pit_state), icp_pit_init);
-sysbus_register_dev("sp804", sizeof(sp804_state), sp804_init);
+sysbus_register_withprop(&sp804_info);
 }
 
 device_init(arm_timer_register_devices)
-- 
1.7.5.4

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

On 12/29/2011 06:07 PM, Dor Laor wrote:
> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:

 btw you can get an additional speedup by enabling x2apic, for
 default_send_IPI_mask_logical().

>>> In the host?
>>>
>>
>> In the host, for the guest:
>>
>>   qemu -cpu ...,+x2apic
>>
>
> It seems to me that we should improve our default flags.
> So many times users fail to submit the proper huge command-line
> options that we require. Honestly, we can't blame them, there are so
> many flags and so many use cases its just too hard to get it right for
> humans.
>
> I propose a basic idea and folks are welcome to discuss it:
>
> 1. Improve qemu/kvm defaults
>Break the current backward compatibility (but add a --default-
>backward-compat-mode)

This exists, -M pc-1.0.

> and set better values for:
> - rtc slew time
> - cache=none
> - x2apic, maybe enhance qemu64 or move to -cpu host?

We tried this for 1.0, but it caused regressions.  Need to try again for
1.1.

> - aio=native|threads (auto-sense?)
> - use virtio devices by default

Can't install non-Linux guests.

> - more?
>
>Different defaults may be picked automatically when TCG|KVM used.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 07:36 PM, Peter Maydell wrote:
> On 29 December 2011 17:26, Avi Kivity  wrote:
> > On 12/29/2011 07:22 PM, Peter Maydell wrote:
> >> I think for devices what would be particularly useful would be
> >> if you can write a (simple) test for something at the register
> >> level, which generates an image which you can run on the real
> >> hardware as well as on QEMU. Then you can confirm that your test
> >> case is correct. Otherwise the tests are just going to bake in the
> >> same assumptions/misconceptions about what the hardware does as
> >> the QEMU model.
> >
> > That is exactly qtest.
>
> Am I missing something? I looked at the qtest patches and they seem
> to work by just prodding the device through qemu function calls,
> not by running a guest CPU binary that prods the device.

Sorry, I misread your post.

I guess we can point a qtest test at real hardware too, if something
like vfio is available to provide access to registers and to hook
interrupts.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 11:49 AM, Peter Maydell wrote:

On 29 December 2011 17:26, Avi Kivity  wrote:

On 12/29/2011 07:22 PM, Peter Maydell wrote:

My guess is that a serious attempt at tests covering all the
functionality of a device is probably approximately doubling
the effort required for a device model, incidentally. A
half-hearted attempt probably doesn't buy you much over
automating "boot the guest OS and prod its driver".


Agreed.


The next obvious question is: are we going to make a serious attempt?
(For instance, in a hypothetical tests-required world, would we
tell those nice folks from Samsung "no you can't land your
Exynos patches unless you write 9000+ lines of test cases" ?


The virtio-serial test case I posted was 50 lines in qemu-test.  The 
virtio-serial driver is about ~1500 LOC.  That's about 3%.


I would expect that we at least have some sort of test that could verify that 
the Exynos platform more or less worked as expected.  If that was just booting a 
Linux kernel, that would be fine by me.



I suspect that if we set the bar for new board and device models
that high then the result will largely be that we don't in fact
get new board or device models.)


This is why the barrier needs to be as low as possible.

Regards,

Anthony Liguori


-- PMM

Re: [Qemu-devel] [RFC v2 2/6] qtest: add support for target-i386 -M pc


On 12/29/2011 11:40 AM, Peter Maydell wrote:

On 1 December 2011 18:43, Anthony Liguori  wrote:

This involves forcing the CPU into the halted state if qtest is enabled and
replacing the local APIC with the qtest interrupt controller.

It should be pretty straight forward to do the same for other machine types on
other architectures.


Having to modify every machine type seems to me like a huge red flag that this
is the wrong approach for device level tests. Surely the right thing is to
(a) instantiate the device (b) manipulate it via its publicly exposed interfaces
(ie the memory regions, gpio signals, irqs, etc etc) ?


The problem is the machine creation.  Once we convert everything to QOM 
including machine setup, yes, this is what we can do.


Regards,

Anthony Liguori



Alternatively if you're just testing features of the device as it
is wired up on the board then you want something that generates an
image that can just be run on the unmodified QEMU model; that then
lets you cross check by running your tests on real hardware.

-- PMM

[Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

2011-12-29 Thread Dor Laor


On 12/26/2011 11:05 AM, Avi Kivity wrote:

On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:


btw you can get an additional speedup by enabling x2apic, for
default_send_IPI_mask_logical().


In the host?



In the host, for the guest:

  qemu -cpu ...,+x2apic



It seems to me that we should improve our default flags.
So many times users fail to submit the proper huge command-line options 
that we require. Honestly, we can't blame them, there are so many flags 
and so many use cases its just too hard to get it right for humans.


I propose a basic idea and folks are welcome to discuss it:

1. Improve qemu/kvm defaults
   Break the current backward compatibility (but add a --default-
   backward-compat-mode) and set better values for:
- rtc slew time
- cache=none
- x2apic, maybe enhance qemu64 or move to -cpu host?
- aio=native|threads (auto-sense?)
- use virtio devices by default
- more?

   Different defaults may be picked automatically when TCG|KVM used.

2. External hardening configuration file kept in qemu.git
   For non qemu/kvm specific definitions like the io scheduler we
   should maintain a script in our tree that sets/sense the optimal
   settings of the host kernel (maybe similar one for the guest).

HTH,
Dor

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 29 December 2011 18:35, Anthony Liguori  wrote:
> On 12/29/2011 11:49 AM, Peter Maydell wrote:
>> The next obvious question is: are we going to make a serious attempt?
>> (For instance, in a hypothetical tests-required world, would we
>> tell those nice folks from Samsung "no you can't land your
>> Exynos patches unless you write 9000+ lines of test cases" ?
>
> The virtio-serial test case I posted was 50 lines in qemu-test.  The
> virtio-serial driver is about ~1500 LOC.  That's about 3%.

This just means it's testing only a fraction of what virtio-serial
actually implements (as you note yourself in the comments for the
test case). For serious coverage you'd also need to cover reading(!),
larger quantities of data than single lines, what happens when one end
feeds in data but the other end isn't reading, vmstate save/load,
multiple simultaneous ports, behaviour on close-and-reopen,
whether it works on bigendian targets, benchmarking to identify
possible performance regressions, etc etc. I think that by the time
you've done all that you'll be closer to 1500 lines than 50.

> I would expect that we at least have some sort of test that could verify
> that the Exynos platform more or less worked as expected.  If that was just
> booting a Linux kernel, that would be fine by me.

Yes. There's a large range between "no tests required at all" (essentially
what we have now) and "an equivalent level of device testing to what you
would carry out before sending your hardware design out to be fabbed into
silicon" (which I hope we'd all agree would be ludicrously high for QEMU);
I'm trying to establish where we're attempting to set our bar.

I agree that we'd get a lot of bang-for-the-buck out of basic automated
"boot the guest and prod it" testing that covered most of our platforms.

-- PMM

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On 12/29/2011 02:39 PM, Isaku Yamahata wrote:
> > > ioctl commands:
> > >
> > > UMEM_DEV_CRATE_UMEM: create umem device for qemu
> > > UMEM_DEV_LIST: list created umem devices
> > > UMEM_DEV_REATTACH: re-attach the created umem device
> > > UMEM_DEV_LIST and UMEM_DEV_REATTACH are used when
> > > the process that services page fault disappears or get stack.
> > > Then, administrator can list the umem devices and unblock
> > > the process which is waiting for page.
> > 
> > Ah, I asked about this in my patch comments.  I think this is done
> > better by using SCM_RIGHTS to pass fds along, or asking qemu to launch a
> > new process.
>
> Can you please elaborate? I think those ways you are suggesting doesn't solve
> the issue. Let me clarify the problem.
>
>   process A (typically incoming qemu)
>  |
>  | mmap("/dev/umem") and access those pages triggering page faults
>  | (the file descriptor might be closed after mmap() before page faults)
>  |
>  V
>/dev/umem
>  ^
>  |
>  |
>daemon X resolving page faults triggered by process A
>(typically this daemon forked from incoming qemu:process A)
>
> If daemon X disappears accidentally, there is no one that resolves
> page faults of process A. At this moment process A is blocked due to page
> fault. There is no file descriptor available corresponding to the VMA.
> Here there is no way to kill process A, but system reboot.

qemu can have an extra thread that wait4()s the daemon, and relaunch
it.  This extra thread would not be blocked by the page fault.  It can
keep the fd so it isn't lost.

The unkillability of process A is a security issue; it could be done on
purpose.  Is it possible to change umem to sleep with
TASK_INTERRUPTIBLE, so it can be killed?

> > Introducing a global namespace has a lot of complications attached.
> > 
> > >
> > > UMEM_GET_PAGE_REQUEST: retrieve page fault of qemu process
> > > UMEM_MARK_PAGE_CACHED: mark the specified pages pulled from the source
> > >for daemon
> > >
> > > UMEM_MAKE_VMA_ANONYMOUS: make the specified vma in the qemu process
> > >This is _NOT_ implemented yet.
> > >  anonymous I'm not sure whether this can be 
> > > implemented
> > >  or not.
> > 
> > How do we find out?  This is fairly important, stuff like transparent
> > hugepages and ksm only works on anonymous memory.
>
> I agree that this is important.
> At KVM-forum 2011, Andrea said THP and KSM works with non-anonymous VMA.
> (Or at lease he'll look into those stuff. My memory is vague, though.
>  Please correct me if I'm wrong)

+= Andrea (who can also provide feedback on umem in general)

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 07:16 PM, Anthony Liguori wrote:
>> Would there be device-level tests in qemu-test?
>
>
> qemu-jeos has a kernel build environment for the target so it is also
> possible to build userspace C programs and/or kernel modules so you
> could also write guest tests in C.
>
> So it may actually be reasonable to write a special virtio-test kernel
> module actually.

Better to use vfio or uio for that, IMO.  But qtest is better still.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [RFC 08/11] linux-user: Share {setup, restore}_sigcontext() for mips ABIs

Shared for n32/n64 in arch/mips/kernel/signal.c;
o32 version in arch/mips/kernel/signal32.c.

Signed-off-by: Andreas Färber 
Cc: Richard Henderson 
Cc: Khansa Butt 
---
 linux-user/signal.c |  204 +-
 1 files changed, 102 insertions(+), 102 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index 6eeafcf..a713cb2 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2466,108 +2466,6 @@ struct target_sigcontext {
 };
 #endif
 
-#if defined(TARGET_ABI_MIPSN64)
-
-# warning signal handling not implemented
-
-static void setup_frame(int sig, struct target_sigaction *ka,
-   target_sigset_t *set, CPUState *env)
-{
-fprintf(stderr, "setup_frame: not implemented\n");
-}
-
-static void setup_rt_frame(int sig, struct target_sigaction *ka,
-   target_siginfo_t *info,
-  target_sigset_t *set, CPUState *env)
-{
-fprintf(stderr, "setup_rt_frame: not implemented\n");
-}
-
-long do_sigreturn(CPUState *env)
-{
-fprintf(stderr, "do_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
-long do_rt_sigreturn(CPUState *env)
-{
-fprintf(stderr, "do_rt_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
-#elif defined(TARGET_ABI_MIPSN32)
-
-# warning signal handling not implemented
-
-static void setup_frame(int sig, struct target_sigaction *ka,
-   target_sigset_t *set, CPUState *env)
-{
-fprintf(stderr, "setup_frame: not implemented\n");
-}
-
-static void setup_rt_frame(int sig, struct target_sigaction *ka,
-   target_siginfo_t *info,
-  target_sigset_t *set, CPUState *env)
-{
-fprintf(stderr, "setup_rt_frame: not implemented\n");
-}
-
-long do_sigreturn(CPUState *env)
-{
-fprintf(stderr, "do_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
-long do_rt_sigreturn(CPUState *env)
-{
-fprintf(stderr, "do_rt_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
-#elif defined(TARGET_ABI_MIPSO32)
-
-
-struct sigframe {
-uint32_t sf_ass[4];/* argument save space for o32 
*/
-uint32_t sf_code[2];   /* signal trampoline */
-struct target_sigcontext sf_sc;
-target_sigset_t sf_mask;
-};
-
-struct target_ucontext {
-target_ulong tuc_flags;
-target_ulong tuc_link;
-target_stack_t tuc_stack;
-target_ulong pad0;
-struct target_sigcontext tuc_mcontext;
-target_sigset_t tuc_sigmask;
-};
-
-struct target_rt_sigframe {
-uint32_t rs_ass[4];   /* argument save space for o32 */
-uint32_t rs_code[2];  /* signal trampoline */
-struct target_siginfo rs_info;
-struct target_ucontext rs_uc;
-};
-
-/* Install trampoline to jump back from signal handler */
-static inline int install_sigtramp(unsigned int *tramp,   unsigned int syscall)
-{
-int err;
-
-/*
-* Set up the return code ...
-*
-* li  v0, __NR__foo_sigreturn
-* syscall
-*/
-
-err = __put_user(0x2402 + syscall, tramp + 0);
-err |= __put_user(0x000c  , tramp + 1);
-/* flush_cache_sigtramp((unsigned long) tramp); */
-return err;
-}
-
 static inline int
 setup_sigcontext(CPUState *regs, struct target_sigcontext *sc)
 {
@@ -2711,6 +2609,7 @@ restore_sigcontext(CPUState *regs, struct 
target_sigcontext *sc)
 #endif
 return err;
 }
+
 /*
  * Determine which stack to use..
  */
@@ -2737,6 +2636,107 @@ get_sigframe(struct target_sigaction *ka, CPUState 
*regs, size_t frame_size)
 return (sp - frame_size) & ~7;
 }
 
+#if defined(TARGET_ABI_MIPSN64)
+
+# warning signal handling not implemented
+
+static void setup_frame(int sig, struct target_sigaction *ka,
+   target_sigset_t *set, CPUState *env)
+{
+fprintf(stderr, "setup_frame: not implemented\n");
+}
+
+static void setup_rt_frame(int sig, struct target_sigaction *ka,
+   target_siginfo_t *info,
+  target_sigset_t *set, CPUState *env)
+{
+fprintf(stderr, "setup_rt_frame: not implemented\n");
+}
+
+long do_sigreturn(CPUState *env)
+{
+fprintf(stderr, "do_sigreturn: not implemented\n");
+return -TARGET_ENOSYS;
+}
+
+long do_rt_sigreturn(CPUState *env)
+{
+fprintf(stderr, "do_rt_sigreturn: not implemented\n");
+return -TARGET_ENOSYS;
+}
+
+#elif defined(TARGET_ABI_MIPSN32)
+
+# warning signal handling not implemented
+
+static void setup_frame(int sig, struct target_sigaction *ka,
+   target_sigset_t *set, CPUState *env)
+{
+fprintf(stderr, "setup_frame: not implemented\n");
+}
+
+static void setup_rt_frame(int sig, struct target_sigaction *ka,
+   target_siginfo_t *info,
+  target_sigset_t *set, CPUState *env)
+{
+fprintf(stderr, "setup_rt_frame: not implemented\n");
+}
+
+long do_sigreturn(CPU

[Qemu-devel] [PATCH 05/11] linux-user: Fix sa_flags byte swaps for mips

sa_flags is uint32_t for mips{,n32,64}, so don't use tswapal().

Reported-by: Khansa Butt 
Suggested-by: Richard Henderson 
Signed-off-by: Andreas Färber 
Cc: Ehsan Ul Haq 
---
 linux-user/signal.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index ded12ca..bafbc57 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -587,7 +587,11 @@ int do_sigaction(int sig, const struct target_sigaction 
*act,
 #endif
 if (oact) {
 oact->_sa_handler = tswapal(k->_sa_handler);
+#if defined(TARGET_MIPS)
+oact->sa_flags = bswap32(k->sa_flags);
+#else
 oact->sa_flags = tswapal(k->sa_flags);
+#endif
 #if !defined(TARGET_MIPS)
 oact->sa_restorer = tswapal(k->sa_restorer);
 #endif
@@ -596,7 +600,11 @@ int do_sigaction(int sig, const struct target_sigaction 
*act,
 if (act) {
 /* FIXME: This is not threadsafe.  */
 k->_sa_handler = tswapal(act->_sa_handler);
+#if defined(TARGET_MIPS)
+k->sa_flags = bswap32(act->sa_flags);
+#else
 k->sa_flags = tswapal(act->sa_flags);
+#endif
 #if !defined(TARGET_MIPS)
 k->sa_restorer = tswapal(act->sa_restorer);
 #endif
-- 
1.7.7

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 29 December 2011 17:26, Avi Kivity  wrote:
> On 12/29/2011 07:22 PM, Peter Maydell wrote:
>> My guess is that a serious attempt at tests covering all the
>> functionality of a device is probably approximately doubling
>> the effort required for a device model, incidentally. A
>> half-hearted attempt probably doesn't buy you much over
>> automating "boot the guest OS and prod its driver".
>
> Agreed.

The next obvious question is: are we going to make a serious attempt?
(For instance, in a hypothetical tests-required world, would we
tell those nice folks from Samsung "no you can't land your
Exynos patches unless you write 9000+ lines of test cases" ?
I suspect that if we set the bar for new board and device models
that high then the result will largely be that we don't in fact
get new board or device models.)

-- PMM

[Qemu-devel] [RFC 07/11] linux-user: target_sigcontext for mipsn32 and mips64

Based on arch/mips/include/asm/sigcontext.h.

Signed-off-by: Andreas Färber 
Cc: Richard Henderson 
Cc: Khansa Butt 
---
 linux-user/signal.c |   64 ++
 1 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index 394984d..6eeafcf 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2423,6 +2423,49 @@ void sparc64_get_context(CPUSPARCState *env)
 }
 #endif
 #elif defined(TARGET_MIPS)
+
+#if defined(TARGET_ABI_MIPSO32) || defined(TARGET_ABI_MIPSN32)
+struct target_sigcontext {
+uint32_t   sc_regmask; /* Unused */
+uint32_t   sc_status;  /* Unused */
+uint64_t   sc_pc;
+uint64_t   sc_regs[32];
+uint64_t   sc_fpregs[32];
+uint32_t   sc_acx; /* only n32; was sc_ownedfp */
+uint32_t   sc_fpc_csr;
+uint32_t   sc_fpc_eir; /* Unused */
+uint32_t   sc_used_math;
+uint32_t   sc_dsp; /* dsp status, was sc_ssflags */
+uint32_t   pad0;
+uint64_t   sc_mdhi;
+uint64_t   sc_mdlo;
+uint32_t   sc_hi1; /* Was sc_cause */
+uint32_t   sc_lo1; /* Was sc_badvaddr */
+uint32_t   sc_hi2; /* Was sc_sigset[4] */
+uint32_t   sc_lo2;
+uint32_t   sc_hi3;
+uint32_t   sc_lo3;
+};
+#elif defined(TARGET_ABI_MIPSN64)
+struct target_sigcontext {
+uint64_t sc_regs[32];
+uint64_t sc_fpregs[32];
+uint64_t sc_mdhi;
+uint64_t sc_hi1;
+uint64_t sc_hi2;
+uint64_t sc_hi3;
+uint64_t sc_mdlo;
+uint64_t sc_lo1;
+uint64_t sc_lo2;
+uint64_t sc_lo3;
+uint64_t sc_pc;
+uint32_t sc_fpc_csr;
+uint32_t sc_used_math;
+uint32_t sc_dsp;
+uint32_t sc_reserved;
+};
+#endif
+
 #if defined(TARGET_ABI_MIPSN64)
 
 # warning signal handling not implemented
@@ -2483,27 +2526,6 @@ long do_rt_sigreturn(CPUState *env)
 
 #elif defined(TARGET_ABI_MIPSO32)
 
-struct target_sigcontext {
-uint32_t   sc_regmask; /* Unused */
-uint32_t   sc_status;
-uint64_t   sc_pc;
-uint64_t   sc_regs[32];
-uint64_t   sc_fpregs[32];
-uint32_t   sc_ownedfp; /* Unused */
-uint32_t   sc_fpc_csr;
-uint32_t   sc_fpc_eir; /* Unused */
-uint32_t   sc_used_math;
-uint32_t   sc_dsp; /* dsp status, was sc_ssflags */
-uint32_t   pad0;
-uint64_t   sc_mdhi;
-uint64_t   sc_mdlo;
-target_ulong   sc_hi1; /* Was sc_cause */
-target_ulong   sc_lo1; /* Was sc_badvaddr */
-target_ulong   sc_hi2; /* Was sc_sigset[4] */
-target_ulong   sc_lo2;
-target_ulong   sc_hi3;
-target_ulong   sc_lo3;
-};
 
 struct sigframe {
 uint32_t sf_ass[4];/* argument save space for o32 
*/
-- 
1.7.7

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On 12/29/2011 04:49 PM, Isaku Yamahata wrote:
> > > Great, then we agreed with list/reattach basically.
> > > (Maybe identity scheme needs reconsideration.)
> > 
> > I guess we miscommunicated.  Why is reattach needed?  If you have the
> > fd, nothing else is needed.
>
> What if malicious process close the fd and does page fault intentionally?
> Unkillable process issue remains.
> I think we are talking not only qemu case but also general case.

It's not unkillable.  If you sleep with TASK_INTERRUPTIBLE then you can
process signals.  This includes SIGKILL.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 10:53 AM, Avi Kivity wrote:

On 12/29/2011 06:39 PM, Anthony Liguori wrote:


qemu-test builds a custom guest, entirely from source.  This makes it
possible to efficiently test non-native architectures.  The tests are
written for this minimal environment (which is not straight forward to
do).  This tests will never run on Windows as they are 100% tied to
their environment.

autotest (let's be clear, there is no such thing as kvm autotest
anymore) is a framework for executing third party tests.  It's got
fancy magic to execute in client mode vs. server mode.  There is a
suite of tests that are integrated in autotest that exercise various
types of virtualization functionality.  This suite of tests use a
special config format to determine what they do.

Included in this, is the ability to create a guest from an ISO either
using step files or via a guest-specific mechanism (kickstart, etc.).
The tests are written to be mostly guest agnostic and are therefore
written in Python in a cross platform way.

There is essentially no overlap between the two and calling kvm
autotest superior is like calling the Sun superior to the Moon.


Why not extend autotest do the same thing.  Instead of downloading a
fedora iso it would download a kernel tarball and (cross-)build it.


My plan is to post a qemu-jeos repo that has the build bits for creating the 
kernel/initramfs pair.


qemu-test will then live in qemu.git and just depend on the results of the 
qemu-jeos.git.  I'd maybe even go as far as including the binaries in qemu.git 
but I don't think that would work so well...



My main motivation to merge
qemu-test and kvm autotest is that I fear that qemu-test will be the
only
requirement for committing stuff for qemu and developers will be
excused from
their 'duty' by writing a 50 LOC shell script and assume they done w/
testing.


There is no requirement to write autotest tests to get things merged
into QEMU.  That's is how things are today.

And I don't think there will ever a requirement to write anything that
isn't merged directly into qemu.git.  I'm not going to hold up merging
a feature until another project merges something into their tree.


What about virtio features (we used to depend on the kernel, now on the
spec)?  Seabios?


Those are rare occurrences and have always been a bit awkward.  OTOH, we're 
talking about the critical path of essentially every single feature that gets 
merged into QEMU.



So unless we're going to merge KVM autotest into qemu.git, I don't
think there's every going to be a requirement to write a KVM autotest
test in order to get something merged into qemu.git.


Let's consider postcopy live migration being proposed.  In addition to
various unit tests, it also wants an integration test.  So now we need
to write a qemu-test postcopy live migration test, and also autotest
test that tests non-Linux guests, migration under load, with memory
hotplug, etc.


But the integration test is also going to depend on libvirt support for the 
feature.  So how does this all get orchestrated?  kvm-autotest merges the test 
case first, then QEMU merges the support, then libvirt?  What about VDSM and 
ovirt-engine?  Once kvm-autotest starts supporting VDSM that's yet another 
component to deal with.


Realistically, kvm-autotest is going to have to wait for the bits to get merged 
in all of the necessary pieces and then build a test for it on their own schedule.



But since autotest is a framework for running third-party tests, it
seems to make sense for qemu.git to have a test framework that
autotest can execute.

And since what we call KVM autotest actually tests a heck of a lot
more than just QEMU, it makes sense for KVM autotest to continue to
focus on full stack testing where QEMU is but one of the many
components that it tests.


It might have made sense to split the kvm-testing functionality of
autotest, and have autotest drive that.  We could even have called it
qemu-test.


I specifically advocated this during Lucas' KVM Forum talk and he was strongly 
opposed to it.


I think kvm autotest would get a lot more interest if the test cases were pulled 
out of autotest, made more stand alone.  They also should be more Unix like 
being divided into individual executables with independent command line options 
over a single do-everything configuration file.


But that's all independent of qemu-test.  qemu-test is really qtest + 
Linux/busybox as a libOS.  Even if the above happened, I would still think 
qemu-test needed to exist.


Regards,

Anthony Liguori

[Qemu-devel] [PATCH v5 7/7] arm: make the number of GIC interrupts configurable

Increase the maximum number of GIC interrupts for a9mp and a11mp to 256,
and create a configurable property for each defaulting to 96 and 64
(respectively) so that device modelers can set the value appropriately
for their SoC. Other ARM processors also set their maximum number of
used IRQs appropriately.

Set the maximum theoretically number of GIC interrupts to 1020 and
update the save/restore code to only use the appropriate number for
each SoC.

Signed-off-by: Mark Langsdorf 
---
Changes from v4
None
Changes from v3
Increase maximum number of GIC interrupts to 1020
Remove SoC/implementation specific GIC_NIRQ #defs
Added properties code to arm11mp
Changed error handling for too many interrupts
Redid save/load handling
Changes from v2
Skipped
Changes from v1
Increase the number of a9mp interrupts to 192
Add a property defaulting to 96
Add a num_irq member in the gic state structure
Use the num_irq value as appropriate
Add num_irq argument to gic_init()
Add num_irq to various CPU calls to gic_init

 hw/a9mpcore.c |7 +++--
 hw/arm11mpcore.c  |   14 +++-
 hw/arm_gic.c  |   57 +---
 hw/armv7m_nvic.c  |7 ++---
 hw/realview_gic.c |3 +-
 5 files changed, 48 insertions(+), 40 deletions(-)

diff --git a/hw/a9mpcore.c b/hw/a9mpcore.c
index 3ef0e13..8c8b72b 100644
--- a/hw/a9mpcore.c
+++ b/hw/a9mpcore.c
@@ -11,9 +11,8 @@
 #include "sysbus.h"
 
 /* Configuration for arm_gic.c:
- * number of external IRQ lines, max number of CPUs, how to ID current CPU
+ * max number of CPUs, how to ID current CPU
  */
-#define GIC_NIRQ 96
 #define NCPU 4
 
 static inline int
@@ -37,6 +36,7 @@ typedef struct a9mp_priv_state {
 MemoryRegion ptimer_iomem;
 MemoryRegion container;
 DeviceState *mptimer;
+uint32_t num_irq;
 } a9mp_priv_state;
 
 static uint64_t a9_scu_read(void *opaque, target_phys_addr_t offset,
@@ -153,7 +153,7 @@ static int a9mp_priv_init(SysBusDevice *dev)
 hw_error("a9mp_priv_init: num-cpu may not be more than %d\n", NCPU);
 }
 
-gic_init(&s->gic, s->num_cpu);
+gic_init(&s->gic, s->num_cpu, s->num_irq);
 
 s->mptimer = qdev_create(NULL, "arm_mptimer");
 qdev_prop_set_uint32(s->mptimer, "num-cpu", s->num_cpu);
@@ -216,6 +216,7 @@ static SysBusDeviceInfo a9mp_priv_info = {
 .qdev.reset = a9mp_priv_reset,
 .qdev.props = (Property[]) {
 DEFINE_PROP_UINT32("num-cpu", a9mp_priv_state, num_cpu, 1),
+DEFINE_PROP_UINT32("num-irq", a9mp_priv_state, num_irq, 256),
 DEFINE_PROP_END_OF_LIST(),
 }
 };
diff --git a/hw/arm11mpcore.c b/hw/arm11mpcore.c
index bc0457e..e4e4bb3 100644
--- a/hw/arm11mpcore.c
+++ b/hw/arm11mpcore.c
@@ -10,11 +10,6 @@
 #include "sysbus.h"
 #include "qemu-timer.h"
 
-/* ??? The MPCore TRM says the on-chip controller has 224 external IRQ lines
-   (+ 32 internal).  However my test chip only exposes/reports 32.
-   More importantly Linux falls over if more than 32 are present!  */
-#define GIC_NIRQ 64
-
 #define NCPU 4
 
 static inline int
@@ -37,6 +32,7 @@ typedef struct mpcore_priv_state {
 MemoryRegion iomem;
 MemoryRegion container;
 DeviceState *mptimer;
+uint32_t num_irq;
 } mpcore_priv_state;
 
 /* Per-CPU private memory mapped IO.  */
@@ -132,7 +128,7 @@ static int mpcore_priv_init(SysBusDevice *dev)
 {
 mpcore_priv_state *s = FROM_SYSBUSGIC(mpcore_priv_state, dev);
 
-gic_init(&s->gic, s->num_cpu);
+gic_init(&s->gic, s->num_cpu, GIC_NIRQ);
 s->mptimer = qdev_create(NULL, "arm_mptimer");
 qdev_prop_set_uint32(s->mptimer, "num-cpu", s->num_cpu);
 qdev_init_nofail(s->mptimer);
@@ -221,6 +217,12 @@ static SysBusDeviceInfo mpcore_priv_info = {
 .qdev.size  = sizeof(mpcore_priv_state),
 .qdev.props = (Property[]) {
 DEFINE_PROP_UINT32("num-cpu", mpcore_priv_state, num_cpu, 1),
+/* The MPCore TRM says the on-chip controller has 224 external
+ * IRQ lines (+ 32 internal).  Some test chips only
+ * expose/report 32. More importantly Linux falls over if more
+ * than 32 are present!  Set the default to 64 and let chips
+ * with more working lines set it higher */
+DEFINE_PROP_UINT32("num-irq", mpcore_priv_state, num_irq, 64),
 DEFINE_PROP_END_OF_LIST(),
 }
 };
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index 0339cf5..5bfb01f 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -11,6 +11,7 @@
controller, MPCore distributed interrupt controller and ARMv7-M
Nested Vectored Interrupt Controller.  */
 
+#define GIC_NIRQ 1020
 //#define DEBUG_GIC
 
 #ifdef DEBUG_GIC
@@ -111,6 +112,7 @@ typedef struct gic_state
 struct gic_state *backref[NCPU];
 MemoryRegion cpuiomem[NCPU+1]; /* CPU interfaces */
 #endif
+int num_irq;
 } gic_state;
 
 /* TODO: Many places that call this routine could be optimized.  */
@@ -133,7 +135,7 @@ static void gi

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 06:26 PM, Anthony Liguori wrote:
> On 12/28/2011 11:21 AM, Avi Kivity wrote:
>> On 12/28/2011 06:42 PM, Anthony Liguori wrote:
 In fact using linux as a guest negates that.  First of all, which
 linux
 version? if it's fixed, you'll eventually miss functionality and
 need to
 migrate.  If it keeps changing, so does your test, and it will keep
 breaking.
>>>
>>>
>>> The kernel is a git submodule so it's a very specific version.  Yes,
>>> we may need to bump the version down the road and obviously, if we
>>> have to change any tests in the process, we can.
>>
>> Having a full linux source as part of the build process detracts
>> somewhat from the advantages here.
>
> Except that binaries can be made available.  The initramfs is
> currently 512k while the kernel is about 5MB.
>
> OTOH, a Fedora install runs in the multiple GB.  Having
> kernels/initramfs for the dozen target types that QEMU supports is
> reasonable.  Having Fedora installs for all of them probably isn't for
> most people.

Then use DSL for the ping test.

>
>>> But there's certain things that I still consider to be unit testing
>>> (like basic networking tests) that I don't want to have to write with
>>> qtest.  I'm not up for writing a TCP/IP stack in Python...
>>
>> A ping test is not a unit test.
>>
>> The ping test is already covered by kvm-autotest; just set up a config
>> that runs just that; after the initial run you'll have a guest installed
>> so it'll be quick.  If we have a DSL guest it'll even be very quick.
>
> Achieving this with kvm-autotest is not easy.  I doubt that DSL has an
> automated install mechanism and the step file based guest installation
> is fincky at best.
>
> When we had the kvm-autotest day, none of the folks that tried to set
> it up who had never set it up before had something working by the end
> of the day.  And that was with lmr available on IRC to answer questions.
>
> There is a huge setup cost with kvm-autotest.

That needs to be fixed, not workarounded.  I previously advised Lucas
not to spend too much time on this, since the audience is limited and it
would be hard to amortize the effort.  Now I see that this was wrong.

>
>> To test the various NIC emulations, you don't need a full TCP stack,
>> just like you didn't need to write an NTP implementation for qtest's rtc
>> test.  Instead you just poke values until it sends out a packet.  If you
>> want to test virtio-net with both direct and indirect buffers, you can
>> only do that with a unit test, you can't do it using a full linux guest
>> since it has its own ideas of when to use indirects and when to avoid
>> them (for example, it may choose to always avoid them).
>
> I am not advocating that we don't write proper unit tests...

Right, and qtest is dangerously close to making writing tests fun.  But
qemu-test is a wierd cross between qtest and kvm-autotest.

>
>>> Acceptance testing is, "does Windows boot", "can I create three
>>> virtio-serial devices".
>>>
>>> Obviously, part of acceptance testing is, "does this set of functional
>>> tests pass".
>>
>> Seems like a very blurry line.  Especially as the functional test is
>> weaker than either qtest and kvm-autotest.  I now have to agree with the
>> others that it's duplicate functionality.  Does it really matter whether
>> you're creating an image by compiling Linux and assembling and
>> initramfs, or by downloading Fedora.iso and installing it?
>
> Yes.  One of them is built entirely from source and the other is doing
> something meant to be done on bare metal.
>
> How do you test ARM guests with kvm-autotest?  There is no such thing
> as an ISO installer for ARM.  Are we going to download random images
> from the internet?

Do exactly what you plan to do with qemu-test.

>
> Even if there is an ISO, installing a guest with TCG will take many
> hours.  My local qemu-test repo can now fully bootstrap an initramfs
> for non-x86 targets (which involves building gcc and uClibc).  Start
> to finish it takes about 30 minutes regardless of the target (since
> the build runs natively).

You can skip the install test and only do the boot test.  Seed your disk
with images from qemu.org or by running the install.  kvm-autotest does
this.

>
>> Would you add live migration testing to qemu-test?  If yes, you're
>> duplicating some more.  If not, you're not doing functional or coverage
>> tests for that functionality.
>
> I would add live migration schema testing, absolutely.  I wouldn't add
> an acceptance test though.
>
> An acceptance test with live migration would be creating a guest,
> running it, and then seeing it live migration worked.

Then it's duplicate functionality.  It's already been done, but the
setup procedure is hard, so let's do it again.

>
>>> I don't want to write a TCP/IP stack.  We aren't just grabbing a
>>> random distro kernel.  We're building one from scratch configured in a
>>> specific way.
>>
>> How does that help?
>
> Not sure I understand t

[Qemu-devel] [PATCH] Init win32 CRITICAL_SECTION before starting thread; crash when attaching disks

2011-12-29 Thread Bogdan Harjoc

Git commit 8d3bc51 crashes on win32 on startup because qemu_tcg_init_vcpu
calls:

qemu_thread_create(th, qemu_tcg_cpu_thread_fn, ...
...
qemu_thread_get_handle(th)

which locks th->data->cs, a CRITICAL_SECTION which is initialized only in
the thread_fn, so it finds garbage.

Attached patch initializes it before calling _beginthreadex. GDB/windbg
probably start newly created threads sooner, because this doesn't happen
under a debugger.

With the patch below it boots until it crashes somewhere while attaching
disks (-hda raw_img).

"bt" in gdb only returns "#0  0x in ??" and generate-core-file
didn't work.

Cheers,

diff -du qemu-8d3bc51\qemu-thread-win32.c
qemu-8d3bc51-new\qemu-thread-win32.c
--- qemu-8d3bc51\qemu-thread-win32.cTue Dec 27 17:28:58 2011
+++ qemu-8d3bc51-new\qemu-thread-win32.cThu Dec 29 18:59:50 2011
@@ -215,8 +215,6 @@
 if (data->mode == QEMU_THREAD_DETACHED) {
 g_free(data);
 data = NULL;
-} else {
-InitializeCriticalSection(&data->cs);
 }
 TlsSetValue(qemu_thread_tls_index, data);
 qemu_thread_exit(start_routine(thread_arg));
@@ -287,6 +285,10 @@
 data->arg = arg;
 data->mode = mode;
 data->exited = false;
+
+if (data->mode != QEMU_THREAD_DETACHED) {
+InitializeCriticalSection(&data->cs);
+}

 hThread = (HANDLE) _beginthreadex(NULL, 0, win32_start_routine,
   data, 0, &thread->tid);

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

On (Thu) 29 Dec 2011 [15:16:55], Christian Borntraeger wrote:
> >> +++ b/hw/virtio-serial-bus.c
> >> @@ -163,7 +163,19 @@ static void do_flush_queued_data(VirtIOS
> >>  abort();
> >>  }
> >>  if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> >> -virtio_serial_throttle_port(port, true);
> > 
> > I'm surprised: did you test this with upstream qemu?  That codebase
> > doesn't yet throttle writes, and this code path won't execute.  Does
> > it really not reproduce with this patch?
> 
> I think 
> static void handle_output(VirtIODevice *vdev, VirtQueue *vq)
> []
> if (!port->throttled) {
> do_flush_queued_data(port, vq, vdev);
> return;
> 
> makes a difference here, since we will never return the buffer to the guest, 
> no?

port->throttled never becomes true for qemu.  I'm just unsure how this
patch works for you :)

Amit

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 11:08 AM, Avi Kivity wrote:

On 12/29/2011 06:53 PM, Anthony Liguori wrote:

In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?



I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to write qtest tests.

Overtime, that libOS will become increasingly complex up until the
point where it approaches something that feels like an actual OS.
Effort spent developing libOS is a cost to building test cases.

By using Linux and a minimal userspace as our libOS, we can avoid
spending a lot of time building a sophisticated libOS.  If we need
advanced libOS features, we just use qemu-test.  If it's just a matter
of poking some registers on a device along, we just use qtest.


Would there be device-level tests in qemu-test?


What is a "device-level" test?

Take a look at:

http://git.qemu.org/?p=qemu-test.git;a=blob;f=scripts/bin/fingerprint;h=2d4202a826917b16856a2acb4617f623fdc4c0d3;hb=HEAD

It's reading BAR0 from any virtio devices to determine the guest features 
exposed.  Yes, it's written in sh :-)  It uses the BAR mappings that sysfs exposes.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On Thu, Dec 29, 2011 at 04:55:11PM +0200, Avi Kivity wrote:
> On 12/29/2011 04:49 PM, Isaku Yamahata wrote:
> > > > Great, then we agreed with list/reattach basically.
> > > > (Maybe identity scheme needs reconsideration.)
> > > 
> > > I guess we miscommunicated.  Why is reattach needed?  If you have the
> > > fd, nothing else is needed.
> >
> > What if malicious process close the fd and does page fault intentionally?
> > Unkillable process issue remains.
> > I think we are talking not only qemu case but also general case.
> 
> It's not unkillable.  If you sleep with TASK_INTERRUPTIBLE then you can
> process signals.  This includes SIGKILL.

Hmm, you said that the fault handler doesn't resolve the page fault.

> > Don't resolve the page fault.  It's up to the user/system to make sure
> > it happens.  qemu can easily do it by watching for the daemon's death
> > and respawning it.

To kill the process, the fault handler must return resolving the fault.
It must return something. What do you expect? VM_FAULT_SIGBUS? zero page?
-- 
yamahata

[Qemu-devel] [PATCH v5 4/7] arm: add dummy gic security registers

From: Rob Herring 

Implement handling for the RAZ/WI gic security registers.

Signed-off-by: Rob Herring 
Signed-off-by: Mark Langsdorf 
Reviewed-by: Peter Maydell 
---
Changes from v2, v3, v4
None
Changes from v1
Moved handling back inside the 0-0x100 block
Added more clarifying comments

 hw/arm_gic.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index 9b52119..0339cf5 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -282,6 +282,10 @@ static uint32_t gic_dist_readb(void *opaque, 
target_phys_addr_t offset)
 return ((GIC_NIRQ / 32) - 1) | ((NUM_CPU(s) - 1) << 5);
 if (offset < 0x08)
 return 0;
+if (offset >= 0x80) {
+/* Interrupt Security , RAZ/WI */
+return 0;
+}
 #endif
 goto bad_reg;
 } else if (offset < 0x200) {
@@ -413,6 +417,8 @@ static void gic_dist_writeb(void *opaque, 
target_phys_addr_t offset,
 DPRINTF("Distribution %sabled\n", s->enabled ? "En" : "Dis");
 } else if (offset < 4) {
 /* ignored.  */
+} else if (offset >= 0x80) {
+/* Interrupt Security Registers, RAZ/WI */
 } else {
 goto bad_reg;
 }
-- 
1.7.5.4

[Qemu-devel] [RFC 06/11] linux-user: Unify signal handling for mips

As suggested by Richard.

Signed-off-by: Andreas Färber 
Cc: Richard Henderson 
Cc: Khansa Butt 
---
 linux-user/signal.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index bafbc57..394984d 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2422,7 +2422,8 @@ void sparc64_get_context(CPUSPARCState *env)
 force_sig(TARGET_SIGSEGV);
 }
 #endif
-#elif defined(TARGET_ABI_MIPSN64)
+#elif defined(TARGET_MIPS)
+#if defined(TARGET_ABI_MIPSN64)
 
 # warning signal handling not implemented
 
@@ -2908,6 +2909,7 @@ badframe:
 return 0;
 }
 
+#endif /* TARGET_ABI_MIPSO32 */
 #elif defined(TARGET_SH4)
 
 /*
-- 
1.7.7

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On 12/29/2011 06:00 PM, Avi Kivity wrote:
> The NFS client has exactly the same issue, if you mount it with the intr
> option.  In fact you could use the NFS client as a trivial umem/cuse
> prototype.

Actually, NFS can return SIGBUS, it doesn't care about restarting daemons.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH 02/11] linux-user: Add default configs for mips64[el]

Prepares for mips64[el]-linux-user targets.

Signed-off-by: Khansa Butt 
Signed-off-by: Andreas Färber 
---
 default-configs/mips64-linux-user.mak   |1 +
 default-configs/mips64el-linux-user.mak |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 default-configs/mips64-linux-user.mak
 create mode 100644 default-configs/mips64el-linux-user.mak

diff --git a/default-configs/mips64-linux-user.mak 
b/default-configs/mips64-linux-user.mak
new file mode 100644
index 000..1598bfc
--- /dev/null
+++ b/default-configs/mips64-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for mips64-linux-user
diff --git a/default-configs/mips64el-linux-user.mak 
b/default-configs/mips64el-linux-user.mak
new file mode 100644
index 000..629f084
--- /dev/null
+++ b/default-configs/mips64el-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for mips64el-linux-user
-- 
1.7.7

Re: [Qemu-devel] [PATCH 2/3] target-mips:enabling of 64 bit user mode and floating point operations MIPS_HFLAG_UX is included in env->hflags so that the address computation for LD instruction does not

Am 29.12.2011 08:55, schrieb Khansa Butt:
> On Fri, Dec 9, 2011 at 5:04 AM, Andreas Färber  wrote:
>>> +/* if cpu has FPU, MIPS_HFLAG_F64 must be included in env->hflags
>>> +   so that floating point operations can be emulated */
>>> +env->active_fpu.fcr0 = env->cpu_model->CP1_fcr0;
>>>  if (env->active_fpu.fcr0 & (1 << FCR0_F64)) {
>>>  env->hflags |= MIPS_HFLAG_F64;
>>>  }
>>
>> Nack. env->active_fpu.fcr0 gets initialized in translate_init.c based on
>> cpu_model->CR1_fcr0, where FCR0_F64 is set only for 24Kf, 34Kf,
>> MIPS64R2-generic. TARGET_ABI_MIPSN64 linux-user defaults to 20Kc. So it
>> seems to rather be an issue of using the right -cpu parameter or
>> changing the default for n64. [cc'ing Nathan, who introduced the if]
> 
> The reason why I add this line " env->active_fpu.fcr0 =
> env->cpu_model->CP1_fcr0" is as follows
> in translate_init.c fpu_init() initializes active_fpu for given cpu
> model afterwards cpu_reset() reset the values
> to zero using this
> memset(env, 0, offsetof(CPUMIPSState, breakpoints));
> so whatever the value of  cpu_model->CR1_fcr0 was , the value of
> env->active_fpu.fcr0 will be zero now  thats why I add above
> line to retrieve the correct env->active_fpu.fcr0 value according to
> CPU model( whether it is 24Kf or 20Kc or something else)
> During the development of mips64-linux-user I observed this issue. I
> gave qemu-mips64 command with -cpu option equal to MIPS64R2-generic
> and an illegal instruction error occurred, so I used above hunk.

Well, that sounds like a different and more generic problem that
shouldn't be fixed inside CONFIG_USER_ONLY && TARGET_MIPS64.
And your reasoning should've definitely been in the commit message!

The problem here is not whether the patches observably work for you but
whether it's the correct way to fix it. "We did this because it works
for us" is never a convincing justification of a change.
If it doesn't work for you in linux-user it won't work in softmmu
either, so doing that before #if defined(CONFIG_USER_ONLY) where lots of
env->cpu_model stuff is being copyied (esp. before env->HABITS to honor
mips_def_t order) seems better.

Also, given your observation, does it even make sense for
cpu_mips_init() to call fpu_init() when all CPUState members it
initializes get cleared in cpu_reset()? Maybe just move that call into
cpu_reset() and rename it to fpu_reset()? mmu_init() and mvp_init() seem
okay by contrast.

When you've figured this out, please again put it into a separate patch
titled, e.g., "target-mips: Fix FPU reset" with appropriate explanation.

Andreas

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 07:10 PM, Anthony Liguori wrote:
> On 12/29/2011 11:03 AM, Avi Kivity wrote:
>> On 12/29/2011 06:49 PM, Anthony Liguori wrote:
 However, I don't think it's even necessary.  From a quick read of the
 manual, SMBIOS is just a set of static tables in memory which are
 picked
 up using a signature.  So all we need to do is boot an empty guest,
 read
 its memory, and look for the tables.
>>>
>>> Doesn't it sound a whole nicer use linux.git to parse this information
>>> for us in a friendly, easy to consume fashion?
>>
>> Run 'dmidecode -d /path/to/memory/dump', if you must.
>>
>> I don't think the qemu-test approach is bad, per se, it's just that
>> qtest is better.  It gives you full control over what to fingerprint and
>> is not reliant on Linux not changing.
>
> Maybe.  But I feel a lot more comfortable asking people to write
> qemu-test's than writing low level logic to do this stuff in qtest.

Writing the libOS is definitely a job for the (sub-)maintainers.  The
work to code a unit test for patch X should be O(X).

>>> IRQs.  I think MSI takes a side channel directly to the local APIC, no?
>>
>> Yes, writes to the 1MB @ 0xfee0 gets translated to MSIs.  So you
>> just translate them to events.
> I currently replace the I/O APIC which seems to be limited to 16
>
> Ah, okay, I wasn't thinking of that.  I'll clean qtest up and resubmit
> next week.

Great.  I'll be happy to help writing libOS.

>>> It also seemed to be reasonably complicated without a clear
>>> advantage.  qtest isn't going to be a supported protocol so we can
>>> certainly change it down the road if we want to.
>>
>> It's a pity not to reuse all the tooling?  Seems like self-NIH.
>
>
> No, it's just going to be more work to reuse things.   I was careful
> to make sure that it was possible down the road.
>
> We have a bit of way to go before the QAPI infrastructure is generic
> enough to be used for something like this.

I've started to simplify the build procedure, maybe it will help a tiny bit.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/28/2011 11:26 AM, Avi Kivity wrote:

On 12/28/2011 06:44 PM, Anthony Liguori wrote:

On 12/28/2011 09:28 AM, Avi Kivity wrote:

On 12/28/2011 05:01 PM, Avi Kivity wrote:

I'd say that running a ping test is a weak version of kvm-autotest's
system tests. Running a synthetic test that pokes values into memory
and mmio and sees a packet coming out is a unit test (the latter can in
fact be executed without a guest at all, just a table driving calls to
the memory and irq APIs).

Consider
98d23704138e0
7b4252e83f6f7d
f7e80adf3cc4
c16ada980f43
4abf12f4ea8

(found by looking for 'fix' in the commit log and filtering out the
commits that don't support my case)

how can you reject such patches on the grounds that they're not
accompanied by unit tests?

That's why I've also proposed qtest. But having written quite a few
qtest unit tests by now, you hit the limits of this type of testing
pretty quickly.

Can you describe those limits?

I started writing a finger print test. While it's easy to do PCI enumeration,
it gets pretty nasty if you want to actually access BARs (to read virtio
registers) and forget about trying to get SMBIOS information as that involves
mucking around with ACPI.

OTOH, it was very simple to write with qemu-test:

http://git.qemu.org/?p=qemu-test.git;a=blob;f=tests/finger-print.sh;h=fc715378a3bbae0b458cc419981c2493d98f5c3d;hb=HEAD

And I ended up finding some long standing bugs in the process:

http://mid.gmane.org/1324305949-20960-2-git-send-email-aligu...@us.ibm.com

It's fairly nasty as it would only show up if doing migration from a new QEMU
with a new guest to a old QEMU.

I think it's a good example of the type of test that I'm targeting at qemu-test.
It's really not interesting to run it across multiple distro types. But doing
it with qtest would be prohibitively hard.

only by making it easy to add tests for
them. I think it would be hard/impossible to test them with
linux-as-a-guest, since they fix edge cases that linux doesn't invoke.
But by having our own driver (often just using qmp to poke at memory),
we can easily generate the sequence that triggers the error.

We'd probably need a library to support setting up a pci device's BARs,
but that's easy with qmp/python integration. You can even poke a small
executable into memory and execute it directly, if you really need guest
cpu interaction.

Please review the qtest series. I think it offers a pretty good
approach to writing this style of test. But as I mentioned, you hit
the limits pretty quickly.

I think it's great, it looks like exactly what I wanted, except it's
been delivered on time.

Can you take a look at how interrupts are handled? From what I gather, the only
real limitation of this approach is that we won't be able to simulate MSI
vectors but I don't think that's a huge problem.

I looked at integrating interrupt handling at CPUs itself and that turned out to
be fairly invasive.

I'd really like to see it integrated quickly
with some flesh around it, then replying -ENOTEST to all patches. This
will improve qemu's quality a lot more than guest boot/ping tests, which
we do regularly with kvm-autotest anyway.

Think of how new instruction emulations are always accompanied by new
kvm-unit-tests tests, I often don't even have to ask for them.

Yes, this is exactly where I'm heading with all of this.

Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 11:22 AM, Avi Kivity wrote:

On 12/29/2011 07:14 PM, Anthony Liguori wrote:

On 12/29/2011 11:08 AM, Avi Kivity wrote:

On 12/29/2011 06:53 PM, Anthony Liguori wrote:

In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?

I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to write qtest tests.

Overtime, that libOS will become increasingly complex up until the
point where it approaches something that feels like an actual OS.
Effort spent developing libOS is a cost to building test cases.

By using Linux and a minimal userspace as our libOS, we can avoid
spending a lot of time building a sophisticated libOS. If we need
advanced libOS features, we just use qemu-test. If it's just a matter
of poking some registers on a device along, we just use qtest.

Would there be device-level tests in qemu-test?

What is a "device-level" test?

A test that tests just one device (or a patch to a single device's
device emulation).

Take a look at:

http://git.qemu.org/?p=qemu-test.git;a=blob;f=scripts/bin/fingerprint;h=2d4202a826917b16856a2acb4617f623fdc4c0d3;hb=HEAD

It's reading BAR0 from any virtio devices to determine the guest
features exposed. Yes, it's written in sh :-)

It would be trivial once libos exists. And we need libos so we can
-ENOTEST device patches, yes?

Or qemu-test. I'd be happy with a test like the virtio-serial test that I
posted for qemu-test.

I expect we'll have a solid libos for x86 but I doubt we'll ever have a solid
libos for other targets.

Regards,

Anthony Liguori

It uses the BAR mappings that sysfs exposes.

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On Thu, Dec 29, 2011 at 01:24:32PM +0200, Avi Kivity wrote:
> On 12/29/2011 03:26 AM, Isaku Yamahata wrote:
> > This is Linux kernel driver for qemu/kvm postcopy live migration.
> > This is used by qemu/kvm postcopy live migration patch.
> >
> > TODO:
> > - Consider FUSE/CUSE option
> >   So far several mmap patches for FUSE/CUSE are floating around. (their
> >   purpose isn't different from our purpose, though). They haven't merged
> >   into the upstream yet.
> >   The driver specific part in qemu patches is modularized. So I expect it
> >   wouldn't be difficult to switch kernel driver to CUSE based driver.
> 
> It would be good to get more input about this, please involve lkml and
> the FUSE/CUSE people.

Okay.


> > ioctl commands:
> >
> > UMEM_DEV_CRATE_UMEM: create umem device for qemu
> > UMEM_DEV_LIST: list created umem devices
> > UMEM_DEV_REATTACH: re-attach the created umem device
> >   UMEM_DEV_LIST and UMEM_DEV_REATTACH are used when
> >   the process that services page fault disappears or get stack.
> >   Then, administrator can list the umem devices and unblock
> >   the process which is waiting for page.
> 
> Ah, I asked about this in my patch comments.  I think this is done
> better by using SCM_RIGHTS to pass fds along, or asking qemu to launch a
> new process.

Can you please elaborate? I think those ways you are suggesting doesn't solve
the issue. Let me clarify the problem.

  process A (typically incoming qemu)
 |
 | mmap("/dev/umem") and access those pages triggering page faults
 | (the file descriptor might be closed after mmap() before page faults)
 |
 V
   /dev/umem
 ^
 |
 |
   daemon X resolving page faults triggered by process A
   (typically this daemon forked from incoming qemu:process A)

If daemon X disappears accidentally, there is no one that resolves
page faults of process A. At this moment process A is blocked due to page
fault. There is no file descriptor available corresponding to the VMA.
Here there is no way to kill process A, but system reboot.


> Introducing a global namespace has a lot of complications attached.
> 
> >
> > UMEM_GET_PAGE_REQUEST: retrieve page fault of qemu process
> > UMEM_MARK_PAGE_CACHED: mark the specified pages pulled from the source
> >for daemon
> >
> > UMEM_MAKE_VMA_ANONYMOUS: make the specified vma in the qemu process
> >  This is _NOT_ implemented yet.
> >  anonymous I'm not sure whether this can be 
> > implemented
> >  or not.
> 
> How do we find out?  This is fairly important, stuff like transparent
> hugepages and ksm only works on anonymous memory.

I agree that this is important.
At KVM-forum 2011, Andrea said THP and KSM works with non-anonymous VMA.
(Or at lease he'll look into those stuff. My memory is vague, though.
 Please correct me if I'm wrong)
-- 
yamahata

[Qemu-devel] [PATCH v5 6/7] Add xgmac ethernet model

This adds very basic support for XG-mac ethernet core from Synopsis and
others. Missing things include:

- statistics counters
- WoL support
- rx checksum offload
- chained descriptors (only linear descriptor ring)
- broadcast and multicast handling

Signed-off-by: Rob Herring 
Signed-off-by: Mark Langsdorf 
---
Changes from v4
None
Changes from v3
Added debug macro and cleaned up some debug code
Refitted all lines to fit within 80 columns
Changes from v2
None
Changes from v1
Reformated most lines to fit within 80 columns
Removed a bunch of unused variables in the state structures
Got rid of some camelcase structure names
Added vmstate support

 Makefile.target |1 +
 hw/xgmac.c  |  424 +++
 2 files changed, 425 insertions(+), 0 deletions(-)
 create mode 100644 hw/xgmac.c

diff --git a/Makefile.target b/Makefile.target
index db5e44c..94cb9ff 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -340,6 +340,7 @@ obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
 obj-arm-y += pl061.o
+obj-arm-y += xgmac.o
 obj-arm-y += arm-semi.o
 obj-arm-y += pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o
 obj-arm-y += pxa2xx_lcd.o pxa2xx_mmci.o pxa2xx_pcmcia.o pxa2xx_keypad.o
diff --git a/hw/xgmac.c b/hw/xgmac.c
new file mode 100644
index 000..c19fff5
--- /dev/null
+++ b/hw/xgmac.c
@@ -0,0 +1,424 @@
+/*
+ * QEMU model of XGMAC Ethernet.
+ *
+ * derived from the Xilinx AXI-Ethernet by Edgar E. Iglesias.
+ *
+ * Copyright (c) 2011 Calxeda, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "sysbus.h"
+#include "qemu-char.h"
+#include "qemu-log.h"
+#include "net.h"
+#include "net/checksum.h"
+
+#ifdef DEBUG_XGMAC
+#define DEBUGF_BRK(message, args...) do { \
+ fprintf(stderr, (message), ## args); \
+ } while (0)
+#else
+#define DEBUGF_BRK(message, args...) do { } while (0)
+#endif
+
+#define XGMAC_CONTROL   0x   /* MAC Configuration */
+#define XGMAC_FRAME_FILTER  0x0001   /* MAC Frame Filter */
+#define XGMAC_FLOW_CTRL 0x0006   /* MAC Flow Control */
+#define XGMAC_VLAN_TAG  0x0007   /* VLAN Tags */
+#define XGMAC_VERSION   0x0008   /* Version */
+/* VLAN tag for insertion or replacement into tx frames */
+#define XGMAC_VLAN_INCL 0x0009
+#define XGMAC_LPI_CTRL  0x000a   /* LPI Control and Status */
+#define XGMAC_LPI_TIMER 0x000b   /* LPI Timers Control */
+#define XGMAC_TX_PACE   0x000c   /* Transmit Pace and Stretch */
+#define XGMAC_VLAN_HASH 0x000d   /* VLAN Hash Table */
+#define XGMAC_DEBUG 0x000e   /* Debug */
+#define XGMAC_INT_STATUS0x000f   /* Interrupt and Control */
+/* HASH table registers */
+#define XGMAC_HASH(n)   ((0x0300/4) + (n))
+#define XGMAC_NUM_HASH  16
+/* Operation Mode */
+#define XGMAC_OPMODE(0x0400/4)
+/* Remote Wake-Up Frame Filter */
+#define XGMAC_REMOTE_WAKE   (0x0700/4)
+/* PMT Control and Status */
+#define XGMAC_PMT   (0x0704/4)
+
+#define XGMAC_ADDR_HIGH(reg)(0x0010+((reg) * 2))
+#define XGMAC_ADDR_LOW(reg) (0x0011+((reg) * 2))
+
+#define DMA_BUS_MODE0x03c0   /* Bus Mode */
+#define DMA_XMT_POLL_DEMAND 0x03c1   /* Transmit Poll Demand */
+#define DMA_RCV_POLL_DEMAND 0x03c2   /* Received Poll Demand */
+#define DMA_RCV_BASE_ADDR   0x03c3   /* Receive List Base */
+#define DMA_TX_BASE_ADDR0x03c4   /* Transmit List Base */
+#define DMA_STATUS  0x03c5   /* Status Register */
+#define DMA_CONTROL 0x03c6   /* Ctrl (Operational Mode) */
+#define DMA_INTR_ENA

Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions

On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
> >Can't figure this out. What does this do?
> Bios will panic if it founds prefmem BARs in both 32bit and 64bit areas.

That's not good, it's a legal configuration.

> Otherwise we will pick one which exists or 32bit one if both are not
> present.

[Qemu-devel] [PATCH v5 1/7] arm: add missing scu registers

From: Rob Herring 

Add power control register to a9mpcore

Signed-off-by: Rob Herring 
Signed-off-by: Mark Langsdorf 
Reviewed-by: Peter Maydell 
---
Changes from v3, v4
None
Changes from v2:
Better handling of byte and halfword writes to the power register
Correct handling of VMState versions
Improved commit message
Changes from v1:
Added VMState support
Checked alignment of writes to the power control register

 hw/a9mpcore.c |   36 +---
 1 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/hw/a9mpcore.c b/hw/a9mpcore.c
index cd2985f..3ef0e13 100644
--- a/hw/a9mpcore.c
+++ b/hw/a9mpcore.c
@@ -29,6 +29,7 @@ gic_get_current_cpu(void)
 typedef struct a9mp_priv_state {
 gic_state gic;
 uint32_t scu_control;
+uint32_t scu_status;
 uint32_t old_timer_status[8];
 uint32_t num_cpu;
 qemu_irq *timer_irq;
@@ -48,7 +49,13 @@ static uint64_t a9_scu_read(void *opaque, target_phys_addr_t 
offset,
 case 0x04: /* Configuration */
 return (((1 << s->num_cpu) - 1) << 4) | (s->num_cpu - 1);
 case 0x08: /* CPU Power Status */
-return 0;
+return s->scu_status;
+case 0x09: /* CPU status.  */
+return s->scu_status >> 8;
+case 0x0a: /* CPU status.  */
+return s->scu_status >> 16;
+case 0x0b: /* CPU status.  */
+return s->scu_status >> 24;
 case 0x0c: /* Invalidate All Registers In Secure State */
 return 0;
 case 0x40: /* Filtering Start Address Register */
@@ -67,12 +74,35 @@ static void a9_scu_write(void *opaque, target_phys_addr_t 
offset,
  uint64_t value, unsigned size)
 {
 a9mp_priv_state *s = (a9mp_priv_state *)opaque;
+uint32_t mask;
+uint32_t shift;
+switch (size) {
+case 1:
+mask = 0xff;
+break;
+case 2:
+mask = 0x;
+break;
+case 4:
+mask = 0x;
+break;
+default:
+fprintf(stderr, "Invalid size %u in write to a9 scu register %x\n",
+size, offset);
+return;
+}
+
 switch (offset) {
 case 0x00: /* Control */
 s->scu_control = value & 1;
 break;
 case 0x4: /* Configuration: RO */
 break;
+case 0x08: case 0x09: case 0x0A: case 0x0B: /* Power Control */
+shift = (offset - 0x8) * 8;
+s->scu_status &= ~(mask << shift);
+s->scu_status |= ((value & mask) << shift);
+break;
 case 0x0c: /* Invalidate All Registers In Secure State */
 /* no-op as we do not implement caches */
 break;
@@ -80,7 +110,6 @@ static void a9_scu_write(void *opaque, target_phys_addr_t 
offset,
 case 0x44: /* Filtering End Address Register */
 /* RAZ/WI, like an implementation with only one AXI master */
 break;
-case 0x8: /* CPU Power Status */
 case 0x50: /* SCU Access Control Register */
 case 0x54: /* SCU Non-secure Access Control Register */
 /* unimplemented, fall through */
@@ -169,11 +198,12 @@ static int a9mp_priv_init(SysBusDevice *dev)
 
 static const VMStateDescription vmstate_a9mp_priv = {
 .name = "a9mpcore_priv",
-.version_id = 1,
+.version_id = 2,
 .minimum_version_id = 1,
 .fields = (VMStateField[]) {
 VMSTATE_UINT32(scu_control, a9mp_priv_state),
 VMSTATE_UINT32_ARRAY(old_timer_status, a9mp_priv_state, 8),
+VMSTATE_UINT32_V(scu_status, a9mp_priv_state, 2),
 VMSTATE_END_OF_LIST()
 }
 };
-- 
1.7.5.4

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 29 December 2011 17:26, Avi Kivity  wrote:
> On 12/29/2011 07:22 PM, Peter Maydell wrote:
>> I think for devices what would be particularly useful would be
>> if you can write a (simple) test for something at the register
>> level, which generates an image which you can run on the real
>> hardware as well as on QEMU. Then you can confirm that your test
>> case is correct. Otherwise the tests are just going to bake in the
>> same assumptions/misconceptions about what the hardware does as
>> the QEMU model.
>
> That is exactly qtest.

Am I missing something? I looked at the qtest patches and they seem
to work by just prodding the device through qemu function calls,
not by running a guest CPU binary that prods the device.

-- PMM

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

2011-12-29 Thread Blue Swirl

On Thu, Dec 29, 2011 at 19:04, Peter Maydell  wrote:
> On 29 December 2011 18:35, Anthony Liguori  wrote:
>> On 12/29/2011 11:49 AM, Peter Maydell wrote:
>>> The next obvious question is: are we going to make a serious attempt?
>>> (For instance, in a hypothetical tests-required world, would we
>>> tell those nice folks from Samsung "no you can't land your
>>> Exynos patches unless you write 9000+ lines of test cases" ?
>>
>> The virtio-serial test case I posted was 50 lines in qemu-test.  The
>> virtio-serial driver is about ~1500 LOC.  That's about 3%.
>
> This just means it's testing only a fraction of what virtio-serial
> actually implements (as you note yourself in the comments for the
> test case). For serious coverage you'd also need to cover reading(!),
> larger quantities of data than single lines, what happens when one end
> feeds in data but the other end isn't reading, vmstate save/load,
> multiple simultaneous ports, behaviour on close-and-reopen,
> whether it works on bigendian targets, benchmarking to identify
> possible performance regressions, etc etc. I think that by the time
> you've done all that you'll be closer to 1500 lines than 50.

The coverage point of view is interesting. I'd expect the coverage
rate to rise as one moves from qtest via qemu-test to autotest.
However, I'd also expect that having qtest and qemu-test would both
increase chances that patches also get test coverage.

Gathering test coverage data could be a start.

>> I would expect that we at least have some sort of test that could verify
>> that the Exynos platform more or less worked as expected.  If that was just
>> booting a Linux kernel, that would be fine by me.
>
> Yes. There's a large range between "no tests required at all" (essentially
> what we have now) and "an equivalent level of device testing to what you
> would carry out before sending your hardware design out to be fabbed into
> silicon" (which I hope we'd all agree would be ludicrously high for QEMU);
> I'm trying to establish where we're attempting to set our bar.
>
> I agree that we'd get a lot of bang-for-the-buck out of basic automated
> "boot the guest and prod it" testing that covered most of our platforms.

That may also be too simplistic. For example, sparc-test (boot Sparc32
Linux with busybox) does not catch doubleword access problems or
certain bugs in floating point point emulation. For those, I need a
boot from an install CD which starts X.

Overall, I'd think that all of qtest, qemu-test and autotest have
their place. If one brilliant day autotest becomes so lean and mean
that qemu-test is unnecessary, it can be deprecated.

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 06:49 PM, Anthony Liguori wrote:
> On 12/29/2011 10:36 AM, Avi Kivity wrote:
>> On 12/29/2011 06:12 PM, Anthony Liguori wrote:
> That's why I've also proposed qtest.  But having written quite a few
> qtest unit tests by now, you hit the limits of this type of testing
> pretty quickly.

 Can you describe those limits?
>>>
>>>
>>> I started writing a finger print test.  While it's easy to do PCI
>>> enumeration, it gets pretty nasty if you want to actually access BARs
>>> (to read virtio registers)
>>
>> Why is that? it should be pretty easy to poke values into the BAR
>> registers.
>
> You have to map them which means you need to figure out what the
> memory layout looks like.  Since there's no BIOS, you need to poke
> fw_cfg to figure all of this out and then program the BARs appropriately.
>
> It's definitely non-trivial.

Or just map sequentially at 0xe000 ascending.

>
>> Something else we can do is access the BARs directly.  We have APIs to
>> poke values into mmio, add an api to poke a value into a device's BAR.
>> Now that each BAR is represented by exactly one memory region, known to
>> the pci core even if it is not mapped, it should be easy.
>>
>>> and forget about trying to get SMBIOS information as that involves
>>> mucking around with ACPI.
>>
>> SMBIOS is built by seabios, yes?
>
> I think QEMU actually builds the blob of information and passes the
> full blob to SeaBIOS.  You could read and parse the blob out of fw_cfg
> I guess but that's still pretty sucky.  It's a lot nicer to just poke
> sysfs.

Seems like two lines of code, either way.

>
>> So fingerprinting it should be done
>> from seabios-test.git.  Let's divide it into two problems:
>
> That seems awkward especially since fingerprinting Just Works with
> qemu-test already (and it was only 50 lines of shell code!).
>
>> - seabios pokes qemu to get information.  We should fingerprint this
>> information to make sure different qemu version can interoperate with
>> different seabios versions (needed since we migrate the bios along with
>> the rest of the guest).  I'm guessing most of this info is from fwcfg?
>> We can easily fingerprint it like any other device.
>> - we need to make sure seabios generates the same tables when using -M.
>> Here, we're not testing a device, rather we're testing guest code, so it
>> makes sense to use a guest for this.
>>
>> However, I don't think it's even necessary.  From a quick read of the
>> manual, SMBIOS is just a set of static tables in memory which are picked
>> up using a signature.  So all we need to do is boot an empty guest, read
>> its memory, and look for the tables.
>
> Doesn't it sound a whole nicer use linux.git to parse this information
> for us in a friendly, easy to consume fashion?

Run 'dmidecode -d /path/to/memory/dump', if you must.

I don't think the qemu-test approach is bad, per se, it's just that
qtest is better.  It gives you full control over what to fingerprint and
is not reliant on Linux not changing.

>>
>> Yes; but using Linux limits you to what it exposes (of course Linux
>> exposes quite a lot, so that's mostly a non issue; but we'll have
>> counterexamples).
>
>
> Maybe.  And for those counter examples, we can drill down to qtest. 
> But just because we may need to do fancy things, it doesn't mean we
> shouldn't take the easy approach 95% of the time.

I guess we have to see how difficult it will be with qtest.  My feeling
is that it will be very easy.

>> I don't see why.  A python library to read pci config should be a couple
>> of dozens of lines long.  Then you iterate over all functions and print
>> selected registers.
>
>
> PCI enumeration is easy.  It's mapping the bars and then poking other
> sources of information that's more challenging.
>
> Everything is doable by writing a libOS but I'd rather just use Linux
> than invent a libOS just for testing.

We will have to write a libOS to test devices.  To test, say, virtio-net
with indirect buffers, you have to map BARs (or poke unmapped BARs
directly).

>>
>> You mention in the changelog replacing the APIC.  Why can't you do that?
>  
>
> I currently replace the I/O APIC which seems to be limited to 16
> IRQs.  I think MSI takes a side channel directly to the local APIC, no?

Yes, writes to the 1MB @ 0xfee0 gets translated to MSIs.  So you
just translate them to events.

>> It looks great.  One thing I'd change is to use the qmp protocol
>> (perhaps not the monitor, just the schema/codegen).  Does something
>> prohibit this?
>
>
> Yeah, I thought about using QMP.  But events are posted in QMP which
> means that you never get an explicit ACK.  That may not be a problem
> but it's something I had in mind.
>
> It also seemed to be reasonably complicated without a clear
> advantage.  qtest isn't going to be a supported protocol so we can
> certainly change it down the road if we want to.

It's a pity not to reuse all the tooling?  Seems like self-NIH.

-- 
error compiling com

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 11:03 AM, Avi Kivity wrote:

On 12/29/2011 06:49 PM, Anthony Liguori wrote:

However, I don't think it's even necessary.  From a quick read of the
manual, SMBIOS is just a set of static tables in memory which are picked
up using a signature.  So all we need to do is boot an empty guest, read
its memory, and look for the tables.


Doesn't it sound a whole nicer use linux.git to parse this information
for us in a friendly, easy to consume fashion?


Run 'dmidecode -d /path/to/memory/dump', if you must.

I don't think the qemu-test approach is bad, per se, it's just that
qtest is better.  It gives you full control over what to fingerprint and
is not reliant on Linux not changing.


Maybe.  But I feel a lot more comfortable asking people to write qemu-test's 
than writing low level logic to do this stuff in qtest.


Maybe over time, we'll have a good enough libOS for qtest that qemu-test won't 
be that useful anymore.  But in the short term, I think we'll get more test 
coverage by having both.




You mention in the changelog replacing the APIC.  Why can't you do that?



I currently replace the I/O APIC which seems to be limited to 16
IRQs.  I think MSI takes a side channel directly to the local APIC, no?


Yes, writes to the 1MB @ 0xfee0 gets translated to MSIs.  So you
just translate them to events.


Ah, okay, I wasn't thinking of that.  I'll clean qtest up and resubmit next 
week.


It looks great.  One thing I'd change is to use the qmp protocol
(perhaps not the monitor, just the schema/codegen).  Does something
prohibit this?



Yeah, I thought about using QMP.  But events are posted in QMP which
means that you never get an explicit ACK.  That may not be a problem
but it's something I had in mind.

It also seemed to be reasonably complicated without a clear
advantage.  qtest isn't going to be a supported protocol so we can
certainly change it down the road if we want to.


It's a pity not to reuse all the tooling?  Seems like self-NIH.


No, it's just going to be more work to reuse things.   I was careful to make 
sure that it was possible down the road.


We have a bit of way to go before the QAPI infrastructure is generic enough to 
be used for something like this.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

On (Thu) 29 Dec 2011 [13:47:43], Christian Borntraeger wrote:
> From: Christian Borntraeger 
> 
> when I tried qemu with -virtio-console pty the guest hangs and attaching on 
> /dev/pts/ does
> not return anything if the attachement is too late.
> Turns out that the console is already throttled and the guest is heavily 
> spinning but get_buf
> never returns the buffer. There seems to be no way for the console to 
> unthrottle the port.

It doesn't really get throttled, since the throttling
enabling/disabling isn't yet done in QEMU.  What happens is that the
chardev buffer gets filled up and qemu_chr_fe_write() doesn't return
-- send_all() keeps spinning.

I'll adjust the commit log message and submit.

Thanks.

Amit

Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions

On Thu, Dec 29, 2011 at 06:41:36PM +1300, Alexey Korolev wrote:
> On 29/12/11 00:43, Michael S. Tsirkin wrote:
> >On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
> >>All devices behind a bridge need to have all their regions consecutive and
> >>not overlapping with all the normal memory ranges.
> >>Since prefetchable memory is described by one record, we must avoid the 
> >>situations
> >>when 32bit and 64bit prefetchable regions are present within one secondary 
> >>bus.
> >How do we avoid this? Assume we have two devices:
> >a 32 bit and a 64 bit one, behind a bridge.
> >There are two main things we can do:
> >1. Make the 64 bit device only use the low 32 bit
>  It was my first implementation. Unfortunately older versions of
> Linux (Like 2.6.18) hang during startup with this.

Can you find out why? qemu has a flag to easily debug
guests with gdb, shouldn't be hard.

> As far as I remember it was qemu-0.15 so may be 1.0 have no such an
> issue. I will check this.
> >2. Put the 32 bit one in the non-prefetcheable range
> I'd rather not do this. Bios should not change memory region types.
> It will confuse guest OS drivers.
> >
> >1 probably makes more sense for small BARs
> >2 probably makes more sense for large ones
> >
> >Try also looking at e.g. linux bus scanning code for more ideas.
> 
> >Another thing I don't see addressed here is that support for 64 bit
> >ranges is I think optional in the bridge.
> >
> >>Signed-off-by: Alexey Korolev
> >Whitespace is corrupted: checkyour mail setup?
> >There should be spaces around operators:
> >a<  b, I see a<  b. Sometimes a<   b (two spaces after).
> Yes, it's thunderbird :(. Sorry about that.
> It seems the patches need to have some functional changes anyway.
> >>---
> >>  src/pciinit.c |   69 
> >> +++-
> >>  1 files changed, 48 insertions(+), 21 deletions(-)
> >>
> >>diff --git a/src/pciinit.c b/src/pciinit.c
> >>index a574e38..92942d5 100644
> >>--- a/src/pciinit.c
> >>+++ b/src/pciinit.c
> >>@@ -17,6 +17,7 @@
> >>
> >>  #define PCI_BRIDGE_IO_MIN  0x1000
> >>  #define PCI_BRIDGE_MEM_MIN   0x10
> >>+#define PCI_BRIDGE_MEM_MAX   0x8000
> >>
> >>  enum pci_region_type {
> >>  PCI_REGION_TYPE_IO,
> >>@@ -45,6 +46,7 @@ struct pci_bus {
> >>  s64 base;
> >>  s64 bases[32 - PCI_MEM_INDEX_SHIFT];
> >>  } r[PCI_REGION_TYPE_COUNT];
> >>+int is64;
> >>  struct pci_device *bus_dev;
> >>  };
> >>
> >>@@ -369,6 +371,26 @@ static void pci_bios_bus_reserve(struct pci_bus *bus, 
> >>int type, u32 size)
> >>  bus->r[type].max = size;
> >>  }
> >>
> >>+static void pci_bios_secondary_bus_reserve(struct pci_bus *parent,
> >>+   struct pci_bus *s, int type)
> >>+{
> >>+u32 limit = (type == PCI_REGION_TYPE_IO) ?
> >>+PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
> >>+
> >>+if (s->r[type].sum>   PCI_BRIDGE_MEM_MAX) {
> >>+panic("Size: %08x%08x is too big\n",
> >>+(u32)s->r[type].sum, (u32)(s->r[type].sum>>32));
> >>+}
> >>+s->r[type].size = (u32)s->r[type].sum;
> >>+if (s->r[type].size<   limit)
> >>+s->r[type].size = limit;
> >>+s->r[type].size = pci_size_roundup(s->r[type].size);
> >>+
> >>+pci_bios_bus_reserve(parent, type, s->r[type].size);
> >>+dprintf(1, "size: %x, type %s\n",
> >>+s->r[type].size, region_type_name[type]);
> >>+}
> >>+
> >>  static void pci_bios_check_devices(struct pci_bus *busses)
> >>  {
> >>  dprintf(1, "PCI: check devices\n");
> >>@@ -392,8 +414,10 @@ static void pci_bios_check_devices(struct pci_bus 
> >>*busses)
> >>  pci_bios_bus_reserve(bus, type, size);
> >>  pci->bars[i].addr = val;
> >>  pci->bars[i].size = size;
> >>-if (type == PCI_REGION_TYPE_PREFMEM_64)
> >>+if (type == PCI_REGION_TYPE_PREFMEM_64) {
> >>+bus->is64 = 1;
> >>  i++;
> >>+}
> >>  }
> >>  }
> >>
> >>@@ -404,22 +428,21 @@ static void pci_bios_check_devices(struct pci_bus 
> >>*busses)
> >>  if (!s->bus_dev)
> >>  continue;
> >>  struct pci_bus *parent =&busses[pci_bdf_to_bus(s->bus_dev->bdf)];
> >>+
> >>+if (s->r[PCI_REGION_TYPE_PREFMEM_64].sum&&
> >Space before&&  here and elsewhere.
> >
> >>+   s->r[PCI_REGION_TYPE_PREFMEM].sum) {
> >>+   panic("Sparse PCI prefmem regions on the bus %d\n", 
> >>secondary_bus);
> >>+}
> >>+
> >>+dprintf(1, "PCI: secondary bus %d\n", secondary_bus);
> >>  int type;
> >>  for (type = 0; type<   PCI_REGION_TYPE_COUNT; type++) {
> >>-u32 limit = (type == PCI_REGION_TYPE_IO) ?
> >>-PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
> >>-s->r[type].size = s->r[type].sum;
> >>-if (s->r[type].size<   limit)
> >>-s->r[type].size = limit;
> >>-

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 29 December 2011 16:36, Avi Kivity  wrote:
> Yes; but using Linux limits you to what it exposes (of course Linux
> exposes quite a lot, so that's mostly a non issue; but we'll have
> counterexamples).

Actually IME Linux is pretty conservative about how it uses devices.
A lot of the ARM device models have gaping holes in their emulation
which we've never needed to fix because Linux simply doesn't use
those features (eg the PL080 DMA controller which doesn't actually
implement DMA!)

I think for devices what would be particularly useful would be
if you can write a (simple) test for something at the register
level, which generates an image which you can run on the real
hardware as well as on QEMU. Then you can confirm that your test
case is correct. Otherwise the tests are just going to bake in the
same assumptions/misconceptions about what the hardware does as
the QEMU model.

My guess is that a serious attempt at tests covering all the
functionality of a device is probably approximately doubling
the effort required for a device model, incidentally. A
half-hearted attempt probably doesn't buy you much over
automating "boot the guest OS and prod its driver".

-- PMM

Re: [Qemu-devel] [PATCH 3/3] linux-user:Signal handling for MIPS64

2011-12-29 Thread Khansa Butt

On Wed, Dec 14, 2011 at 9:20 PM, Richard Henderson  wrote:
> On 12/07/2011 09:25 PM, kha...@kics.edu.pk wrote:
>> +#if defined(TARGET_MIPS64)
>> +        /* tswapal() do 64 bit swap in case of MIPS64 but
>> +           we need 32 bit swap as sa_flags is 32 bit */
>> +        k->sa_flags = bswap32(act->sa_flags);
>> +#else
>>          k->sa_flags = tswapal(act->sa_flags);
>> +#endif
>
> The condition in syscall_defs.h is TARGET_MIPS, not TARGET_MIPS64.
> They should match, despite the fact that it doesn't actually matter
> for the 32-bit abis.
>
>>  #elif defined(TARGET_ABI_MIPSN64)
>>
>> -# warning signal handling not implemented
>> +struct target_sigcontext {
>> +    uint32_t   sc_regmask;     /* Unused */
>> +    uint32_t   sc_status;
>
> There's no reason to duplicate all this code.  Yes, when someone wrote
> this in the first place, they wrote separate sectons for each mips abi.
> However, as you can see that huge portions of this block are identical,
> this was obviously a mistake.
>
> Start by changing the original section to #elif defined(TARGET_MIPS)
> and see what needs changing specifically for the ABIs.  I'm not even
> sure there are any differences at all.

The difference lies in setup_frame(). the trampoline function needs
syscall number
install_sigtramp(frame->sf_code, TARGET_NR_sigreturn);
sigreturn is not defined for MIPS64 instead it has only rt_sigreturn.
I tried with #elif defined(TARGET_MIPS). cross compile the following
small program and run it on
qemu-mips64
#include 
#include 
#include 
#include 

struct sigaction act;

void sighandler(int signum, siginfo_t *info, void *ptr)
{
printf("Received signal %d\n", signum);
printf("Signal originates from process %lu\n",(unsigned long)info->si_pid);
}

int main()
{
printf("I am %lu\n", (unsigned long)getpid());

memset(&act, 0, sizeof(act));

act.sa_sigaction = sighandler;
act.sa_flags = SA_SIGINFO;

sigaction(SIGILL, &act, NULL);

// Waiting
sleep(100);

return 0;
}

and again I found that only install_sigtramp line is needed to be changed.
keeping  #elif defined(TARGET_MIPS) above signal handling portion, can i use
 #if defined(TARGET_MIPS64)
 
#else
for install_sigtramp() difference
>
>
> r~

[Qemu-devel] [RFC 11/11] linux-user: Implement signal handling for mipsn32

Mostly adapted from o32.

Linux no longer seems to have sf_code/rs_code for any of the ABIs.
It's u32 {sf,rt}_pad[2] /* Was: signal trampoline */ now...

Signed-off-by: Andreas Färber 
Cc: Richard Henderson 
Cc: Khansa Butt 
---
 linux-user/signal.c |  104 +--
 1 files changed, 100 insertions(+), 4 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index b33f8cb..82ce4ac 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2673,7 +2673,20 @@ long do_rt_sigreturn(CPUState *env)
 
 #elif defined(TARGET_ABI_MIPSN32)
 
-# warning signal handling not implemented
+struct target_ucontext {
+uint32_t tuc_flags;
+int32_t  tuc_link;
+target_stack_t   tuc_stack;
+struct target_sigcontext tuc_mcontext;
+target_sigset_t  tuc_sigmask;
+};
+
+struct target_rt_sigframe {
+uint32_t   rs_ass[4]; /* argument save space for o32 */
+uint32_t   rs_pad[2]; /* Was: signal trampoline */
+struct target_siginfo  rs_info;
+struct target_ucontext rs_uc;
+};
 
 static void setup_frame(int sig, struct target_sigaction *ka,
target_sigset_t *set, CPUState *env)
@@ -2685,7 +2698,61 @@ static void setup_rt_frame(int sig, struct 
target_sigaction *ka,
target_siginfo_t *info,
   target_sigset_t *set, CPUState *env)
 {
-fprintf(stderr, "setup_rt_frame: not implemented\n");
+struct target_rt_sigframe *frame;
+abi_ulong frame_addr;
+int i;
+
+frame_addr = get_sigframe(ka, env, sizeof(*frame));
+if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0))
+   goto give_sigsegv;
+
+//install_sigtramp(frame->rs_pad, TARGET_NR_rt_sigreturn);
+
+/* Create siginfo. */
+copy_siginfo_to_user(&frame->rs_info, info);
+
+/* Create the ucontext. */
+__put_user(0, &frame->rs_uc.tuc_flags);
+__put_user(0, &frame->rs_uc.tuc_link);
+__put_user(target_sigaltstack_used.ss_sp, &frame->rs_uc.tuc_stack.ss_sp);
+__put_user(target_sigaltstack_used.ss_size, 
&frame->rs_uc.tuc_stack.ss_size);
+__put_user(sas_ss_flags(get_sp_from_cpustate(env)),
+   &frame->rs_uc.tuc_stack.ss_flags);
+
+setup_sigcontext(env, &frame->rs_uc.tuc_mcontext);
+
+for(i = 0; i < TARGET_NSIG_WORDS; i++) {
+__put_user(set->sig[i], &frame->rs_uc.tuc_sigmask.sig[i]);
+}
+
+/*
+ * Arguments to signal handler:
+ *
+ *   a0 = signal number
+ *   a1 = pointer to struct siginfo
+ *   a2 = pointer to struct ucontext
+ *
+ * $25 and PC point to the signal handler, $29 points to the
+ * struct sigframe.
+ */
+env->active_tc.gpr[ 4] = sig;
+env->active_tc.gpr[ 5] = frame_addr
+ + offsetof(struct target_rt_sigframe, rs_info);
+env->active_tc.gpr[ 6] = frame_addr
+ + offsetof(struct target_rt_sigframe, rs_uc);
+env->active_tc.gpr[29] = frame_addr;
+//env->active_tc.gpr[31] = frame_addr
+// + offsetof(struct target_rt_sigframe, rs_pad);
+/* The original kernel code sets CP0_EPC to the handler
+ * since it returns to userland using eret
+ * we cannot do this here, and we must set PC directly */
+env->active_tc.PC = env->active_tc.gpr[25] = ka->_sa_handler;
+unlock_user_struct(frame, frame_addr, 1);
+return;
+
+give_sigsegv:
+unlock_user_struct(frame, frame_addr, 1);
+force_sig(TARGET_SIGSEGV/*, current*/);
 }
 
 long do_sigreturn(CPUState *env)
@@ -2696,8 +2763,37 @@ long do_sigreturn(CPUState *env)
 
 long do_rt_sigreturn(CPUState *env)
 {
-fprintf(stderr, "do_rt_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
+struct target_rt_sigframe *frame;
+abi_ulong frame_addr;
+sigset_t blocked;
+
+#if defined(DEBUG_SIGNAL)
+fprintf(stderr, "do_rt_sigreturn\n");
+#endif
+frame_addr = env->active_tc.gpr[29];
+if (!lock_user_struct(VERIFY_READ, frame, frame_addr, 1))
+   goto badframe;
+
+target_to_host_sigset(&blocked, &frame->rs_uc.tuc_sigmask);
+sigprocmask(SIG_SETMASK, &blocked, NULL);
+
+if (restore_sigcontext(env, &frame->rs_uc.tuc_mcontext))
+goto badframe;
+
+if (do_sigaltstack(frame_addr +
+  offsetof(struct target_rt_sigframe, rs_uc.tuc_stack),
+  0, get_sp_from_cpustate(env)) == -EFAULT)
+goto badframe;
+
+env->active_tc.PC = env->CP0_EPC;
+/* I am not sure this is right, but it seems to work
+ * maybe a problem with nested signals ? */
+env->CP0_EPC = 0;
+return -TARGET_QEMU_ESIGRETURN;
+
+badframe:
+force_sig(TARGET_SIGSEGV/*, current*/);
+return 0;
 }
 
 #elif defined(TARGET_ABI_MIPSO32)
-- 
1.7.7

Re: [Qemu-devel] [PATCH 3/3] Changes related to secondary buses and 64bit regions

On Thu, Dec 29, 2011 at 06:40:26PM +1300, Alexey Korolev wrote:
> On 29/12/11 00:43, Michael S. Tsirkin wrote:
> >On Wed, Dec 28, 2011 at 06:35:55PM +1300, Alexey Korolev wrote:
> >>All devices behind a bridge need to have all their regions consecutive and
> >>not overlapping with all the normal memory ranges.
> >>Since prefetchable memory is described by one record, we must avoid the 
> >>situations
> >>when 32bit and 64bit prefetchable regions are present within one secondary 
> >>bus.
> >How do we avoid this? Assume we have two devices:
> >a 32 bit and a 64 bit one, behind a bridge.
> >There are two main things we can do:
> >1. Make the 64 bit device only use the low 32 bit
>  It was my first implementation. Unfortunately older versions of
> Linux (Like 2.6.18) hang during startup with this.
> As far as I remember it was qemu-0.15 so may be 1.0 have no such an
> issue. I will check this.
> >2. Put the 32 bit one in the non-prefetcheable range
> I'd rather not do this. Bios should not change memory region types.
> It will confuse guest OS drivers.

It shouldn't, it's a legal behavious.
Prefetcheable BAR allows certain optimizations but does not
require them.

> >
> >1 probably makes more sense for small BARs
> >2 probably makes more sense for large ones
> >
> >Try also looking at e.g. linux bus scanning code for more ideas.
> 
> >Another thing I don't see addressed here is that support for 64 bit
> >ranges is I think optional in the bridge.
> >
> >>Signed-off-by: Alexey Korolev
> >Whitespace is corrupted: checkyour mail setup?
> >There should be spaces around operators:
> >a<  b, I see a<  b. Sometimes a<   b (two spaces after).
> Yes, it's thunderbird :(. Sorry about that.
> It seems the patches need to have some functional changes.
> >>---
> >>  src/pciinit.c |   69 
> >> +++-
> >>  1 files changed, 48 insertions(+), 21 deletions(-)
> >>
> >>diff --git a/src/pciinit.c b/src/pciinit.c
> >>index a574e38..92942d5 100644
> >>--- a/src/pciinit.c
> >>+++ b/src/pciinit.c
> >>@@ -17,6 +17,7 @@
> >>
> >>  #define PCI_BRIDGE_IO_MIN  0x1000
> >>  #define PCI_BRIDGE_MEM_MIN   0x10
> >>+#define PCI_BRIDGE_MEM_MAX   0x8000
> >>
> >>  enum pci_region_type {
> >>  PCI_REGION_TYPE_IO,
> >>@@ -45,6 +46,7 @@ struct pci_bus {
> >>  s64 base;
> >>  s64 bases[32 - PCI_MEM_INDEX_SHIFT];
> >>  } r[PCI_REGION_TYPE_COUNT];
> >>+int is64;
> >>  struct pci_device *bus_dev;
> >>  };
> >>
> >>@@ -369,6 +371,26 @@ static void pci_bios_bus_reserve(struct pci_bus *bus, 
> >>int type, u32 size)
> >>  bus->r[type].max = size;
> >>  }
> >>
> >>+static void pci_bios_secondary_bus_reserve(struct pci_bus *parent,
> >>+   struct pci_bus *s, int type)
> >>+{
> >>+u32 limit = (type == PCI_REGION_TYPE_IO) ?
> >>+PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
> >>+
> >>+if (s->r[type].sum>   PCI_BRIDGE_MEM_MAX) {
> >>+panic("Size: %08x%08x is too big\n",
> >>+(u32)s->r[type].sum, (u32)(s->r[type].sum>>32));
> >>+}
> >>+s->r[type].size = (u32)s->r[type].sum;
> >>+if (s->r[type].size<   limit)
> >>+s->r[type].size = limit;
> >>+s->r[type].size = pci_size_roundup(s->r[type].size);
> >>+
> >>+pci_bios_bus_reserve(parent, type, s->r[type].size);
> >>+dprintf(1, "size: %x, type %s\n",
> >>+s->r[type].size, region_type_name[type]);
> >>+}
> >>+
> >>  static void pci_bios_check_devices(struct pci_bus *busses)
> >>  {
> >>  dprintf(1, "PCI: check devices\n");
> >>@@ -392,8 +414,10 @@ static void pci_bios_check_devices(struct pci_bus 
> >>*busses)
> >>  pci_bios_bus_reserve(bus, type, size);
> >>  pci->bars[i].addr = val;
> >>  pci->bars[i].size = size;
> >>-if (type == PCI_REGION_TYPE_PREFMEM_64)
> >>+if (type == PCI_REGION_TYPE_PREFMEM_64) {
> >>+bus->is64 = 1;
> >>  i++;
> >>+}
> >>  }
> >>  }
> >>
> >>@@ -404,22 +428,21 @@ static void pci_bios_check_devices(struct pci_bus 
> >>*busses)
> >>  if (!s->bus_dev)
> >>  continue;
> >>  struct pci_bus *parent =&busses[pci_bdf_to_bus(s->bus_dev->bdf)];
> >>+
> >>+if (s->r[PCI_REGION_TYPE_PREFMEM_64].sum&&
> >Space before&&  here and elsewhere.
> >
> >>+   s->r[PCI_REGION_TYPE_PREFMEM].sum) {
> >>+   panic("Sparse PCI prefmem regions on the bus %d\n", 
> >>secondary_bus);
> >>+}
> >>+
> >>+dprintf(1, "PCI: secondary bus %d\n", secondary_bus);
> >>  int type;
> >>  for (type = 0; type<   PCI_REGION_TYPE_COUNT; type++) {
> >>-u32 limit = (type == PCI_REGION_TYPE_IO) ?
> >>-PCI_BRIDGE_IO_MIN : PCI_BRIDGE_MEM_MIN;
> >>-s->r[type].size = s->r[type].sum;
> >>-if (s->r[type].size<   limit)
> >>-s->r[type].size = limit

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 10:46 AM, Avi Kivity wrote:

On 12/29/2011 06:26 PM, Anthony Liguori wrote:

I don't want to write a TCP/IP stack.  We aren't just grabbing a
random distro kernel.  We're building one from scratch configured in a
specific way.


How does that help?


Not sure I understand the question.



In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?


I firmly believe that with qtest we'll end up eventually building a libOS to 
make it easier to write qtest tests.


Overtime, that libOS will become increasingly complex up until the point where 
it approaches something that feels like an actual OS.  Effort spent developing 
libOS is a cost to building test cases.


By using Linux and a minimal userspace as our libOS, we can avoid spending a lot 
of time building a sophisticated libOS.  If we need advanced libOS features, we 
just use qemu-test.  If it's just a matter of poking some registers on a device 
along, we just use qtest.


Guest neutral tests that are meant to run on Linux, Windows, etc. are in a 
completely different ballpark.


Regards,

Anthony Liguori

[Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

From: Christian Borntraeger 

when I tried qemu with -virtio-console pty the guest hangs and attaching on 
/dev/pts/ does
not return anything if the attachement is too late.
Turns out that the console is already throttled and the guest is heavily 
spinning but get_buf
never returns the buffer. There seems to be no way for the console to 
unthrottle the port.

For the virtio-serial use case we dont want to loose data but for the console 
case we better
drop  data instead of "killing" the guest console. If we get chardev->frontend 
notification
and a better behaving virtio-console we can revert this fix.

Signed-off-by: Christian Borntraeger 

---
 hw/virtio-serial-bus.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

Index: b/hw/virtio-serial-bus.c
===
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -163,7 +163,19 @@ static void do_flush_queued_data(VirtIOS
 abort();
 }
 if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
-virtio_serial_throttle_port(port, true);
+   /*
+ * this is a temporary check until chardevs can signal to
+ * frontends that they are writable again. This prevents
+ * the console from going into throttled mode (forever)
+ * if virtio-console is connected to a pty without a
+ * listener. Otherwise the guest spins forever.
+ * We can revert this if
+ * 1: chardevs can notify frondends
+ * 2: the guest driver does not spin in these cases
+ */
+if (!info->is_console) {
+virtio_serial_throttle_port(port, true);
+}
 port->iov_idx = i;
 if (ret > 0) {
 port->iov_offset += ret;

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

2011-12-29 Thread Dor Laor

On 12/28/2011 07:21 PM, Avi Kivity wrote:

I think you're advocating for qtest.  This is another important part
>  of my testing strategy.  I haven't received a lot of input on that RFC...
>
>  http://mid.gmane.org/1322765012-3164-1-git-send-email-aligu...@us.ibm.com
>
>  But there's certain things that I still consider to be unit testing
>  (like basic networking tests) that I don't want to have to write with
>  qtest.  I'm not up for writing a TCP/IP stack in Python...

A ping test is not a unit test.

The ping test is already covered by kvm-autotest; just set up a config
that runs just that; after the initial run you'll have a guest installed
so it'll be quick.  If we have a DSL guest it'll even be very quick.

To test the various NIC emulations, you don't need a full TCP stack,
just like you didn't need to write an NTP implementation for qtest's rtc
test.  Instead you just poke values until it sends out a packet.  If you
want to test virtio-net with both direct and indirect buffers, you can
only do that with a unit test, you can't do it using a full linux guest
since it has its own ideas of when to use indirects and when to avoid
them (for example, it may choose to always avoid them).

>>  I suggest the following:
>>
>> - qemu-test: qemu unit tests
>> - kvm-unit-tests: kvm unit tests
>> - kvm-autotest: unit test drivers + system tests

>
>
>  I would counter with:
>
>  - gtester unit tests (test-visitor, test-qobject, etc., qemu-iotest)

+1 for qtester

>  - qtest: low level, single device functional tests

+1 for it

>  - kvm-unit-tests: low level, instruction-set level functional tests

Not really.  kvm-unit-tests tests things specific to kvm.

>  - qemu-test: higher level functional/coverage tests (multiple device
>interaction)
>  - kvm-autotest: unit/functional test drivers + acceptance testing
>
>  Note that the line I'm drawing is acceptance vs. functional testing,
>  not unit vs. integration testing.  Technically, our unit tests are
>  things like test-visitor.  Everything else is an integration test.
>
>  But the separation between kvm-autotest is acceptance testing vs.
>  functional testing.
>
>  Acceptance testing is, "does Windows boot", "can I create three
>  virtio-serial devices".
>
>  Obviously, part of acceptance testing is, "does this set of functional
>  tests pass".

Seems like a very blurry line.  Especially as the functional test is
weaker than either qtest and kvm-autotest.  I now have to agree with the
others that it's duplicate functionality.  Does it really matter whether
you're creating an image by compiling Linux and assembling and
initramfs, or by downloading Fedora.iso and installing it?  It's testing
exactly the same thing, guest boot and functionality.

Would you add live migration testing to qemu-test?  If yes, you're
duplicating some more.  If not, you're not doing functional or coverage
tests for that functionality.

From the recent threads it looks to me that the 2 advantages of 
qemu-test over kvm-autotest are:

1. python is not used within the guest
2. qemu-test is smaller and simpler

Except for the above 2, kvm autotest is superior. My main motivation to 
merge qemu-test and kvm autotest is that I fear that qemu-test will be 
the only requirement for committing stuff for qemu and developers will 
be excused from their 'duty' by writing a 50 LOC shell script and assume 
they done w/ testing. In addition to that, the 50 LOC will be too basic 
and only provide value for basic functionality tests and kvm autotest 
folks will need to rewrite all of the matching content and beyond.

Those above 2 advantages can be solve:

1. python is not used within the guest
   - One option is just to use the same shell code in kvm autotest w/o
 no python code and use the same kernel/initramfs.
   - Another way is to use a plain linux distro w/ python and boot it
 into single user test mode and potentially use a S4 guest snapshot
 or external snapshot to shorten its boot time.
 You'll get faster boot time and friendlier code.

2. qemu-test is smaller and simpler
   kvm autotest will have a fast, out of the box mode especially
   designed to answer your requirements.
   It's mainly a matter of preparing a fastTestMode.py that will setup
   all of the above in a similar way that today's 
https://github.com/autotest/autotest/blob/master/client/tests/kvm/get_started.py

Lastly, each test can have a fast|basic|sanity overloaded function that 
will be called by this.

>

>>>  We shouldn't be discussing whether it's possible to merge the two
>>>  tools, but rather what the technical benefits of doing so would be.
>>>
>>>  Since at this point, there is almost no overlap between the two, I
>>>  don't see any actual technical benefit to merging them.  I see benefit
>>>  to autotest executing qemu-test, of course.

>>
>>  I'd say that running a ping test is a weak version of kvm-autotest's
>>  system tests.

>
>  Consider the Linux kernel

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 11:08 AM, Avi Kivity wrote:

On 12/29/2011 06:53 PM, Anthony Liguori wrote:

In what way is your specifically configured kernel's TCP stack better
than the random distro's kernel's?



I firmly believe that with qtest we'll end up eventually building a
libOS to make it easier to write qtest tests.

Overtime, that libOS will become increasingly complex up until the
point where it approaches something that feels like an actual OS.
Effort spent developing libOS is a cost to building test cases.

By using Linux and a minimal userspace as our libOS, we can avoid
spending a lot of time building a sophisticated libOS.  If we need
advanced libOS features, we just use qemu-test.  If it's just a matter
of poking some registers on a device along, we just use qtest.


Would there be device-level tests in qemu-test?


qemu-jeos has a kernel build environment for the target so it is also possible 
to build userspace C programs and/or kernel modules so you could also write 
guest tests in C.


So it may actually be reasonable to write a special virtio-test kernel module 
actually.


Regards,

Anthony Liguori

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/28/2011 11:21 AM, Avi Kivity wrote:

On 12/28/2011 06:42 PM, Anthony Liguori wrote:

In fact using linux as a guest negates that.  First of all, which linux
version? if it's fixed, you'll eventually miss functionality and need to
migrate.  If it keeps changing, so does your test, and it will keep
breaking.



The kernel is a git submodule so it's a very specific version.  Yes,
we may need to bump the version down the road and obviously, if we
have to change any tests in the process, we can.


Having a full linux source as part of the build process detracts
somewhat from the advantages here.


Except that binaries can be made available.  The initramfs is currently 512k 
while the kernel is about 5MB.


OTOH, a Fedora install runs in the multiple GB.  Having kernels/initramfs for 
the dozen target types that QEMU supports is reasonable.  Having Fedora installs 
for all of them probably isn't for most people.



But there's certain things that I still consider to be unit testing
(like basic networking tests) that I don't want to have to write with
qtest.  I'm not up for writing a TCP/IP stack in Python...


A ping test is not a unit test.

The ping test is already covered by kvm-autotest; just set up a config
that runs just that; after the initial run you'll have a guest installed
so it'll be quick.  If we have a DSL guest it'll even be very quick.


Achieving this with kvm-autotest is not easy.  I doubt that DSL has an automated 
install mechanism and the step file based guest installation is fincky at best.


When we had the kvm-autotest day, none of the folks that tried to set it up who 
had never set it up before had something working by the end of the day.  And 
that was with lmr available on IRC to answer questions.


There is a huge setup cost with kvm-autotest.


To test the various NIC emulations, you don't need a full TCP stack,
just like you didn't need to write an NTP implementation for qtest's rtc
test.  Instead you just poke values until it sends out a packet.  If you
want to test virtio-net with both direct and indirect buffers, you can
only do that with a unit test, you can't do it using a full linux guest
since it has its own ideas of when to use indirects and when to avoid
them (for example, it may choose to always avoid them).


I am not advocating that we don't write proper unit tests...


Acceptance testing is, "does Windows boot", "can I create three
virtio-serial devices".

Obviously, part of acceptance testing is, "does this set of functional
tests pass".


Seems like a very blurry line.  Especially as the functional test is
weaker than either qtest and kvm-autotest.  I now have to agree with the
others that it's duplicate functionality.  Does it really matter whether
you're creating an image by compiling Linux and assembling and
initramfs, or by downloading Fedora.iso and installing it?


Yes.  One of them is built entirely from source and the other is doing something 
meant to be done on bare metal.


How do you test ARM guests with kvm-autotest?  There is no such thing as an ISO 
installer for ARM.  Are we going to download random images from the internet?


Even if there is an ISO, installing a guest with TCG will take many hours.  My 
local qemu-test repo can now fully bootstrap an initramfs for non-x86 targets 
(which involves building gcc and uClibc).  Start to finish it takes about 30 
minutes regardless of the target (since the build runs natively).



Would you add live migration testing to qemu-test?  If yes, you're
duplicating some more.  If not, you're not doing functional or coverage
tests for that functionality.


I would add live migration schema testing, absolutely.  I wouldn't add an 
acceptance test though.


An acceptance test with live migration would be creating a guest, running it, 
and then seeing it live migration worked.



I don't want to write a TCP/IP stack.  We aren't just grabbing a
random distro kernel.  We're building one from scratch configured in a
specific way.


How does that help?


Not sure I understand the question.

Regards,

Anthony Liguori


In theory, we could even host the kernel source on git.qemu.org and
fork it to add more interesting things in the kernel (although I'd
prefer not to do this, obviously).


That way lies madness, though it could be argued that it lies all around us.

[Qemu-devel] [PATCH 04/11] linux-user: Define TARGET_QEMU_ESIGRETURN for mips64

Copied from mips/syscall.h.

Signed-off-by: Khansa Butt 
Signed-off-by: Andreas Färber 
---
 linux-user/mips64/syscall.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/linux-user/mips64/syscall.h b/linux-user/mips64/syscall.h
index 668a2b9..e436ea5 100644
--- a/linux-user/mips64/syscall.h
+++ b/linux-user/mips64/syscall.h
@@ -218,4 +218,7 @@ struct target_pt_regs {
 
 
 
+/* Nasty hack: define a fake errno value for use by sigreturn. */
+#define TARGET_QEMU_ESIGRETURN 255
+
 #define UNAME_MACHINE "mips64"
-- 
1.7.7

Re: [Qemu-devel] [PATCH 2/2] umem: chardevice for kvm postcopy

On 12/29/2011 02:22 PM, Isaku Yamahata wrote:
> > 
> > A simpler approach is the open("/dev/umem") returns an mmap()able fd. 
> > You need to call an ioctl() to set the size, etc. but only you only
> > operate on that fd.
>
> So you are suggesting that /dev/umem and /dev/umemctl should be introduced
> and split the functionality.

No; perhaps I'm missing some functionality, but I'm suggesting

  fd = open("/dev/umem");
  ftruncate(fd, size);
  struct umem_config config =  { ... };
  ioctl(fd, UMEM_CONFIG, &config);
  mmap(..., fd, size);

> > 
> > IMO, it would be better to avoid names, and use opaque __u64 identifiers
> > assigned by userspace, or perhaps file descriptors generated by the
> > kernel.  With names come the complications of namespaces, etc.  One user
> > can DoS another by grabbing a name that it knows the other user wants to
> > use.
>
> So how about the kernel assigning identifiers which is system global?

Depends on what you do with the identifiers.  Something like reattach
needs security, you can't just reattach to any random umem segment.

It's really best to stick with file descriptors, which already have a
security model.

>
>
> > > +
> > > +struct umem_create {
> > > + __u64 size; /* in bytes */
> > > + __s32 umem_fd;
> > > + __s32 shmem_fd;
> > > + __u32 async_req_max;
> > > + __u32 sync_req_max;
> > > + struct umem_name name;
> > > +};
> > > +
> > > +struct umem_page_request {
> > > + __u64 __user *pgoffs;
> > 
> > Pointers change their size in 32-bit and 64-bit userspace, best to avoid
> > them.
>
> Ah yes, right. How about following?
> struct {
>__u32 nr;
>__u32 padding;
>__u64 pgoffs[0];
> }

Sure.

If we use a pipe to transport requests, you can just send them as a
sequence of __u64 addresses.

> > > +
> > > +/* ioctl for umem fd */
> > > +#define UMEM_GET_PAGE_REQUEST_IOWR(UMEMIO, 0x10, struct 
> > > umem_page_request)
> > > +#define UMEM_MARK_PAGE_CACHED_IOW (UMEMIO, 0x11, struct 
> > > umem_page_cached)
> > 
> > You could make the GET_PAGE_REQUEST / MARK_PAGE_CACHED protocol run over
> > file descriptors, instead of an ioctl.  It allows you to implement the
> > other side in either the kernel or userspace.  This is similar to how
> > kvm uses an eventfd for communication with vhost-net in the kernel, or
> > an implementation in userspace.
>
> Do you mean that read/write on file descriptors is better than ioctl?
> Okay, it would be easy to convert ioctl into read/write.

Yes, they already provide synchronization.  And if you want to implement
a umem provider over RDMA in the kernel, then it's easy to add it; it's
not trivial for the kernel to issue ioctls but reads/writes are easy.

It's also easy to pass file descriptors among processes.

How do FUSE/CUSE pass requests?

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [RFC 00/11] linux-user: Sort out signal handling for MIPS n32 and n64

Hello,

Here's a suggestion for moving forward with mipsn32 and mips64.
For testing add the following to your --target-list:
mips-linux-user
mipsel-linux-user
mipsn32-linux-user
mipsn32el-linux-user
mips64-linux-user
mips64el-linux-user

Patches 1-4 are trivial and hopefully uncontroversial preparations
that can be cherry-picked right away!
The n32 ones are based on a patch by Uli found in openSUSE,
the n64 ones are extracted from Khansa's patch series.

Patch 5 is a bugfix based on a patch by Khansa/Ehsan.

The rest of the patches are in RFC status and attempt to implement
rth's suggestion of sharing signal handling between MIPS ABIs.
Depending on the issue the final patch brings up, even more code
might be shared.

Regards,
Andreas

Cc: Riku Voipio 
Cc: Aurelien Jarno 

Cc: Richard Henderson 
Cc: Khansa Butt 
Cc: Ehsan Ul Haq 
Cc: Ulrich Hecht 
Cc: Brendan Kirby 

Cc: Peter Maydell 
Cc: Alexander Graf 

Andreas Färber (11):
  linux-user: Add default-configs for mipsn32[el]
  linux-user: Add default configs for mips64[el]
  linux-user: Define TARGET_QEMU_ESIGRETURN for mipsn32
  linux-user: Define TARGET_QEMU_ESIGRETURN for mips64
  linux-user: Fix sa_flags byte swaps for mips
  linux-user: Unify signal handling for mips
  linux-user: target_sigcontext for mipsn32 and mips64
  linux-user: Share {setup,restore}_sigcontext() for mips ABIs
  linux-user: Setup/restore sc_acx for mips and mipsn32
  linux-user: mipsn32 does not support non-RT signals
  linux-user: Implement signal handling for mipsn32

 default-configs/mips64-linux-user.mak|1 +
 default-configs/mips64el-linux-user.mak  |1 +
 default-configs/mipsn32-linux-user.mak   |1 +
 default-configs/mipsn32el-linux-user.mak |1 +
 linux-user/mips64/syscall.h  |3 +
 linux-user/mipsn32/syscall.h |3 +
 linux-user/signal.c  |  348 +-
 7 files changed, 251 insertions(+), 107 deletions(-)
 create mode 100644 default-configs/mips64-linux-user.mak
 create mode 100644 default-configs/mips64el-linux-user.mak
 create mode 100644 default-configs/mipsn32-linux-user.mak
 create mode 100644 default-configs/mipsn32el-linux-user.mak

-- 
1.7.7

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 11:06 AM, Avi Kivity wrote:

On 12/29/2011 07:02 PM, Anthony Liguori wrote:


Those are rare occurrences and have always been a bit awkward.  OTOH,
we're talking about the critical path of essentially every single
feature that gets merged into QEMU.



Won't that be qtest?


The difference is that the qtest test can be patch N/N in a patch series and be 
merged at exactly the same time.


I think having an in-tree test suite is the only practical way to do TDD.

Regards,

Anthony Liguori


Let's consider postcopy live migration being proposed.  In addition to
various unit tests, it also wants an integration test.  So now we need
to write a qemu-test postcopy live migration test, and also autotest
test that tests non-Linux guests, migration under load, with memory
hotplug, etc.


But the integration test is also going to depend on libvirt support
for the feature.  So how does this all get orchestrated?  kvm-autotest
merges the test case first, then QEMU merges the support, then
libvirt?  What about VDSM and ovirt-engine?  Once kvm-autotest starts
supporting VDSM that's yet another component to deal with.

Realistically, kvm-autotest is going to have to wait for the bits to
get merged in all of the necessary pieces and then build a test for it
on their own schedule.


It just has to be posted and reviewed, it doesn't all have to be merged
at the same time (and the qemu merge has to precede the autotest merge)

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

Am 29.12.2011 14:27, schrieb Amit Shah:
> On (Thu) 29 Dec 2011 [13:47:43], Christian Borntraeger wrote:
>> From: Christian Borntraeger 
>> 
>> when I tried qemu with -virtio-console pty the guest hangs and attaching on 
>> /dev/pts/ does
>> not return anything if the attachement is too late.

"attachment", while you're at it.

Andreas

>> Turns out that the console is already throttled and the guest is heavily 
>> spinning but get_buf
>> never returns the buffer. There seems to be no way for the console to 
>> unthrottle the port.
> 
> It doesn't really get throttled, since the throttling
> enabling/disabling isn't yet done in QEMU.  What happens is that the
> chardev buffer gets filled up and qemu_chr_fe_write() doesn't return
> -- send_all() keeps spinning.
> 
> I'll adjust the commit log message and submit.
> 
> Thanks.
> 
>   Amit

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 2/3] Add a new PCI region type to supports 64 bit ranges

On Thu, Dec 29, 2011 at 06:32:37PM +1300, Alexey Korolev wrote:
> 
> >>@@ -69,6 +72,8 @@ static enum pci_region_type pci_addr_to_type(u32 addr)
> >>  {
> >>  if (addr&  PCI_BASE_ADDRESS_SPACE_IO)
> >>  return PCI_REGION_TYPE_IO;
> >>+if (addr&  PCI_BASE_ADDRESS_MEM_TYPE_64)
> >>+return PCI_REGION_TYPE_PREFMEM_64;
> >This seems dangerous - a 64bit bar can be non-prefetchable - getting
> >this wrong could cause random (hard to debug) crashes.
> >
> Just out of curiosity - how this could happen? Having 64bit
> non-prefetchable BAR implies that the device is not behind
> any bridge (as bridges describe 64bit ranges for prefetchable
> memory only). Is it possible on nowadays systems?

Yes. qemu puts all devices directly on the root bus.
system devices are also commonly located on the root bus.

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On 12/29/2011 05:53 PM, Isaku Yamahata wrote:
> On Thu, Dec 29, 2011 at 04:55:11PM +0200, Avi Kivity wrote:
> > On 12/29/2011 04:49 PM, Isaku Yamahata wrote:
> > > > > Great, then we agreed with list/reattach basically.
> > > > > (Maybe identity scheme needs reconsideration.)
> > > > 
> > > > I guess we miscommunicated.  Why is reattach needed?  If you have the
> > > > fd, nothing else is needed.
> > >
> > > What if malicious process close the fd and does page fault intentionally?
> > > Unkillable process issue remains.
> > > I think we are talking not only qemu case but also general case.
> > 
> > It's not unkillable.  If you sleep with TASK_INTERRUPTIBLE then you can
> > process signals.  This includes SIGKILL.
>
> Hmm, you said that the fault handler doesn't resolve the page fault.
>
> > > Don't resolve the page fault.  It's up to the user/system to make sure
> > > it happens.  qemu can easily do it by watching for the daemon's death
> > > and respawning it.
>
> To kill the process, the fault handler must return resolving the fault.
> It must return something. What do you expect? VM_FAULT_SIGBUS? zero page?

   if (signal_pending(current))
return VM_FAULT_RETRY;

for SIGKILL, the process dies immediately.  For other unblocked signals,
the process starts executing the signal handler, which isn't dependent
on the faulting page (of course the signal handler may itself fault).

The NFS client has exactly the same issue, if you mount it with the intr
option.  In fact you could use the NFS client as a trivial umem/cuse
prototype.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

>> +++ b/hw/virtio-serial-bus.c
>> @@ -163,7 +163,19 @@ static void do_flush_queued_data(VirtIOS
>>  abort();
>>  }
>>  if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
>> -virtio_serial_throttle_port(port, true);
> 
> I'm surprised: did you test this with upstream qemu?  That codebase
> doesn't yet throttle writes, and this code path won't execute.  Does
> it really not reproduce with this patch?

I think 
static void handle_output(VirtIODevice *vdev, VirtQueue *vq)
[]
if (!port->throttled) {
do_flush_queued_data(port, vq, vdev);
return;

makes a difference here, since we will never return the buffer to the guest, no?

Christian

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 08:38 AM, Dor Laor wrote:

On 12/28/2011 07:21 PM, Avi Kivity wrote:

Would you add live migration testing to qemu-test? If yes, you're
duplicating some more. If not, you're not doing functional or coverage
tests for that functionality.


 From the recent threads it looks to me that the 2 advantages of qemu-test over
kvm-autotest are:

1. python is not used within the guest
2. qemu-test is smaller and simpler

Except for the above 2, kvm autotest is superior.


Sorry, but that's non-sense.

qemu-test builds a custom guest, entirely from source.  This makes it possible 
to efficiently test non-native architectures.  The tests are written for this 
minimal environment (which is not straight forward to do).  This tests will 
never run on Windows as they are 100% tied to their environment.


autotest (let's be clear, there is no such thing as kvm autotest anymore) is a 
framework for executing third party tests.  It's got fancy magic to execute in 
client mode vs. server mode.  There is a suite of tests that are integrated in 
autotest that exercise various types of virtualization functionality.  This 
suite of tests use a special config format to determine what they do.


Included in this, is the ability to create a guest from an ISO either using step 
files or via a guest-specific mechanism (kickstart, etc.).  The tests are 
written to be mostly guest agnostic and are therefore written in Python in a 
cross platform way.


There is essentially no overlap between the two and calling kvm autotest 
superior is like calling the Sun superior to the Moon.



My main motivation to merge
qemu-test and kvm autotest is that I fear that qemu-test will be the only
requirement for committing stuff for qemu and developers will be excused from
their 'duty' by writing a 50 LOC shell script and assume they done w/ testing.


There is no requirement to write autotest tests to get things merged into QEMU. 
 That's is how things are today.


And I don't think there will ever a requirement to write anything that isn't 
merged directly into qemu.git.  I'm not going to hold up merging a feature until 
another project merges something into their tree.


So unless we're going to merge KVM autotest into qemu.git, I don't think there's 
every going to be a requirement to write a KVM autotest test in order to get 
something merged into qemu.git.


But since autotest is a framework for running third-party tests, it seems to 
make sense for qemu.git to have a test framework that autotest can execute.


And since what we call KVM autotest actually tests a heck of a lot more than 
just QEMU, it makes sense for KVM autotest to continue to focus on full stack 
testing where QEMU is but one of the many components that it tests.



In addition to that, the 50 LOC will be too basic and only provide value for
basic functionality tests and kvm autotest folks will need to rewrite all of the
matching content and beyond.

Those above 2 advantages can be solve:

1. python is not used within the guest
- One option is just to use the same shell code in kvm autotest w/o
no python code and use the same kernel/initramfs.


Yes, you can make a directory in kvm autotest that just imports qemu-test, but 
what's the point of doing that?  Isn't it better for this to live in qemu.git?



- Another way is to use a plain linux distro w/ python and boot it
into single user test mode and potentially use a S4 guest snapshot
or external snapshot to shorten its boot time.


You cannot easily create a "plain linux distro" for an ARM target.  If you don't 
believe me, add ARM guest support to KVM autotest and see how well it works out :-)



You'll get faster boot time and friendlier code.


Adding S4 resume for "simple tests" seems to be a bit odd to me...


2. qemu-test is smaller and simpler
kvm autotest will have a fast, out of the box mode especially
designed to answer your requirements.
It's mainly a matter of preparing a fastTestMode.py that will setup
all of the above in a similar way that today's
https://github.com/autotest/autotest/blob/master/client/tests/kvm/get_started.py


I hope you see from the above that this isn't just about having something new 
that has fewer features and is therefore simpler for the time being.


The approach is fundamentally different.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 21/21] postcopy: implement postcopy livemigration

On 12/29/2011 03:26 AM, Isaku Yamahata wrote:
> This patch implements postcopy livemigration.
>
>  
> +/* RAM is allocated via umem for postcopy incoming mode */
> +#define RAM_POSTCOPY_UMEM_MASK  (1 << 1)
> +
>  typedef struct RAMBlock {
>  uint8_t *host;
>  ram_addr_t offset;
> @@ -485,6 +488,10 @@ typedef struct RAMBlock {
>  #if defined(__linux__) && !defined(TARGET_S390X)
>  int fd;
>  #endif
> +
> +#ifdef CONFIG_POSTCOPY
> +UMem *umem;/* for incoming postcopy mode */
> +#endif
>  } RAMBlock;

Is it possible to implement this via the MemoryListener API (which
replaces CPUPhysMemoryClient)?  This is how kvm, vhost, and xen manage
their memory tables.

>  

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 07:22 PM, Peter Maydell wrote:
> On 29 December 2011 16:36, Avi Kivity  wrote:
> > Yes; but using Linux limits you to what it exposes (of course Linux
> > exposes quite a lot, so that's mostly a non issue; but we'll have
> > counterexamples).
>
> Actually IME Linux is pretty conservative about how it uses devices.
> A lot of the ARM device models have gaping holes in their emulation
> which we've never needed to fix because Linux simply doesn't use
> those features (eg the PL080 DMA controller which doesn't actually
> implement DMA!)

We were discussing fingerprinting, not actually driving the device.  For
that, I think we're all agreed that qtest is vastly superior to using an
OS driver.

> I think for devices what would be particularly useful would be
> if you can write a (simple) test for something at the register
> level, which generates an image which you can run on the real
> hardware as well as on QEMU. Then you can confirm that your test
> case is correct. Otherwise the tests are just going to bake in the
> same assumptions/misconceptions about what the hardware does as
> the QEMU model.

That is exactly qtest.

> My guess is that a serious attempt at tests covering all the
> functionality of a device is probably approximately doubling
> the effort required for a device model, incidentally. A
> half-hearted attempt probably doesn't buy you much over
> automating "boot the guest OS and prod its driver".

Agreed.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 06:12 PM, Anthony Liguori wrote:
>>> That's why I've also proposed qtest.  But having written quite a few
>>> qtest unit tests by now, you hit the limits of this type of testing
>>> pretty quickly.
>>
>> Can you describe those limits?
>
>
> I started writing a finger print test.  While it's easy to do PCI
> enumeration, it gets pretty nasty if you want to actually access BARs
> (to read virtio registers) 

Why is that? it should be pretty easy to poke values into the BAR registers.

Something else we can do is access the BARs directly.  We have APIs to
poke values into mmio, add an api to poke a value into a device's BAR. 
Now that each BAR is represented by exactly one memory region, known to
the pci core even if it is not mapped, it should be easy.

> and forget about trying to get SMBIOS information as that involves
> mucking around with ACPI.

SMBIOS is built by seabios, yes?  So fingerprinting it should be done
from seabios-test.git.  Let's divide it into two problems:

- seabios pokes qemu to get information.  We should fingerprint this
information to make sure different qemu version can interoperate with
different seabios versions (needed since we migrate the bios along with
the rest of the guest).  I'm guessing most of this info is from fwcfg? 
We can easily fingerprint it like any other device.
- we need to make sure seabios generates the same tables when using -M. 
Here, we're not testing a device, rather we're testing guest code, so it
makes sense to use a guest for this.

However, I don't think it's even necessary.  From a quick read of the
manual, SMBIOS is just a set of static tables in memory which are picked
up using a signature.  So all we need to do is boot an empty guest, read
its memory, and look for the tables.

>
> OTOH, it was very simple to write with qemu-test:
>
> http://git.qemu.org/?p=qemu-test.git;a=blob;f=tests/finger-print.sh;h=fc715378a3bbae0b458cc419981c2493d98f5c3d;hb=HEAD
>

Yes; but using Linux limits you to what it exposes (of course Linux
exposes quite a lot, so that's mostly a non issue; but we'll have
counterexamples).

>
> And I ended up finding some long standing bugs in the process:
>
> http://mid.gmane.org/1324305949-20960-2-git-send-email-aligu...@us.ibm.com
>
>
> It's fairly nasty as it would only show up if doing migration from a
> new QEMU with a new guest to a old QEMU.

Yes, good catch.

>
> I think it's a good example of the type of test that I'm targeting at
> qemu-test.  It's really not interesting to run it across multiple
> distro types.  But doing it with qtest would be prohibitively hard.

I don't see why.  A python library to read pci config should be a couple
of dozens of lines long.  Then you iterate over all functions and print
selected registers.

>>> Please review the qtest series.  I think it offers a pretty good
>>> approach to writing this style of test.  But as I mentioned, you hit
>>> the limits pretty quickly.
>>
>> I think it's great, it looks like exactly what I wanted, except it's
>> been delivered on time.
>
>
> Can you take a look at how interrupts are handled?  From what I
> gather, the only real limitation of this approach is that we won't be
> able to simulate MSI vectors but I don't think that's a huge problem.
>
> I looked at integrating interrupt handling at CPUs itself and that
> turned out to be fairly invasive.

You mention in the changelog replacing the APIC.  Why can't you do that?

>
>> I'd really like to see it integrated quickly
>> with some flesh around it, then replying -ENOTEST to all patches.  This
>> will improve qemu's quality a lot more than guest boot/ping tests, which
>> we do regularly with kvm-autotest anyway.
>>
>> Think of how new instruction emulations are always accompanied by new
>> kvm-unit-tests tests, I often don't even have to ask for them.
>
> Yes, this is exactly where I'm heading with all of this.

It looks great.  One thing I'd change is to use the qmp protocol
(perhaps not the monitor, just the schema/codegen).  Does something
prohibit this?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] Expose tsc deadline timer cpuid to guest

2011-12-29 Thread Liu, Jinsong

Jan Kiszka wrote:
> On 2011-12-28 18:35, Liu, Jinsong wrote:
 diff --git a/qemu-kvm.h b/qemu-kvm.h
 index 2bd5602..8c6c2ea 100644
 --- a/qemu-kvm.h
 +++ b/qemu-kvm.h
 @@ -260,6 +260,7 @@ extern int kvm_irqchip;
  extern int kvm_pit;
  extern int kvm_pit_reinject;
  extern unsigned int kvm_shadow_memory;
 +extern int tsc_deadline_timer;
 
  int kvm_handle_tpr_access(CPUState *env);
  void kvm_tpr_enable_vapic(CPUState *env);
 diff --git a/qemu-options.hx b/qemu-options.hx
 index f6df6b9..eff6644 100644
 --- a/qemu-options.hx
 +++ b/qemu-options.hx
 @@ -2619,6 +2619,9 @@ DEF("no-kvm-pit-reinjection", 0,
  QEMU_OPTION_no_kvm_pit_reinjection,
  "-no-kvm-pit-reinjection\n" "disable KVM
 kernel mode PIT interrupt reinjection\n",  QEMU_ARCH_I386)
 +DEF("no-tsc-deadline-timer", 0,
 QEMU_OPTION_no_tsc_deadline_timer, +"-no-tsc-deadline-timer
 disable tsc deadline timer\n", +QEMU_ARCH_I386) 
>>> 
>>> Hmm, I would really prefer to stop adding switches like this. They
>>> won't make it upstream anyway.
>> 
>> OK, I will try to write a patch w/ better user control cpuid method,
>> i.e. by plus_features and minus_features. 
> 
> Yep, that would be better.

Thanks, patch updated according to above idea, and sent out.

> 
>> 
>>> 
>>> Can't this control be attached to legacy qemu machine models, ie.
>>> here anything <= pc-1.0? See how we handle kvmclock.
>>> 
>> 
>> You mean, by adding input para like pc_init1(..., kvmclock_enabled,
>> tscdeadline_enabled)? 
>> I think that's not a good way.
> 
> I think it is mandatory as older qemu versions won't expose
> tscdeadline to the guest, thus newer versions must not do this when
> emulating older machines.

Hmm, if an old qemu machine runs at a new host platform (say, -cpu host), it 
would expose many *new* cpuid features to guest.

IMO, qemu machine is a *virt* platform for guest,
tsc deadline timer is a cpuid features, not much necessary to be bound to some 
qemu machine version.
whether tsc deadline timer cpuid expose to guest can only decided by:
1. user authorize enable (default yes)
2. kvm_irqchip_in_kernel
3. KVM_CAP_TSC_DEADLINE_TIMER
If yes, it can be exposed to guest, and would not break anything no matter what 
qemu machine version is.


Thanks,
Jinsong

> 
>> With more and more cpuid features (N) controlled in this way,
>> machine models would be 2^N. 
> 
> We likely need a better way to express this via code, I agree. Likely
> something declarative as for compat_props.
>

[Qemu-devel] [RFC 09/11] linux-user: Setup/restore sc_acx for mips and mipsn32

Signed-off-by: Andreas Färber 
Cc: Richard Henderson 
---
 linux-user/signal.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index a713cb2..bd13f9b 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2487,6 +2487,9 @@ setup_sigcontext(CPUState *regs, struct target_sigcontext 
*sc)
 save_gp_reg(31);
 #undef save_gp_reg
 
+#if defined(TARGET_ABI_MIPSO32) || defined(TARGET_ABI_MIPSN32)
+err |= __put_user(regs->active_tc.ACX[0], &sc->sc_acx);
+#endif
 err |= __put_user(regs->active_tc.HI[0], &sc->sc_mdhi);
 err |= __put_user(regs->active_tc.LO[0], &sc->sc_mdlo);
 
@@ -2548,6 +2551,9 @@ restore_sigcontext(CPUState *regs, struct 
target_sigcontext *sc)
 
 err |= __get_user(regs->CP0_EPC, &sc->sc_pc);
 
+#if defined(TARGET_ABI_MIPSO32) || defined(TARGET_ABI_MIPSN32)
+err |= __get_user(regs->active_tc.ACX[0], &sc->sc_acx);
+#endif
 err |= __get_user(regs->active_tc.HI[0], &sc->sc_mdhi);
 err |= __get_user(regs->active_tc.LO[0], &sc->sc_mdlo);
 
-- 
1.7.7

[Qemu-devel] [PATCH v5 0/7] various ARM fixes for Calxeda Highbank

This is a collection of fixes and additions to the models for various
ARM devices. These changes are needed to support the forthcoming 
Calxeda Highbank SoC model.

 Makefile.target |2 +
 hw/a9mpcore.c   |   43 +-
 hw/arm11mpcore.c|   14 +-
 hw/arm_gic.c|   63 +---
 hw/arm_l2x0.c   |  182 ++
 hw/arm_timer.c  |   24 +++-
 hw/armv7m_nvic.c|7 +-
 hw/realview_gic.c   |3 +-
 hw/xgmac.c  |  424 +++
 target-arm/cpu.h|1 +
 target-arm/helper.c |   14 ++
 11 files changed, 729 insertions(+), 48 deletions(-)

[Qemu-devel] [PATCH v5 3/7] arm: add dummy v7 cp15 config_base_register

Add a cp15 config_base_register that currently defaults to 0.
After the QOM CPU support is added, the value will be properly
set to the periphal base value.

Signed-off-by: Mark Langsdorf 
Reviewed-by: Peter Maydell 
---
Changes from v3, v4
None
Changes from v2
Added test against op2 
Changes from v1
renamed the register
added comments about how it will change when QOM CPUs are added

 target-arm/cpu.h|1 +
 target-arm/helper.c |   14 ++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c4d742f..449e620 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -149,6 +149,7 @@ typedef struct CPUARMState {
 uint32_t c15_i_max; /* Maximum D-cache dirty line index.  */
 uint32_t c15_i_min; /* Minimum D-cache dirty line index.  */
 uint32_t c15_threadid; /* TI debugger thread-ID.  */
+uint32_t c15_config_base_address; /* SCU base address.  */
 } cp15;
 
 struct {
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 65f4fbf..b235fed 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2111,6 +2111,20 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
  * 0x200 << ($rn & 0xfff), when MMU is off.  */
 goto bad_reg;
 }
+if (ARM_CPUID(env) == ARM_CPUID_CORTEXA9) {
+switch (crm) {
+case 0:
+/* The config_base_address should hold the value of
+ * the peripheral base. ARM should get this from a CPU
+ * object property, but that support isn't available in
+ * December 2011. Default to 0 for now and board models
+ * that care can set it by a private hook */
+if ((op1 == 4) && (op2 == 0)) {
+return env->cp15.c15_config_base_address;
+}
+}
+goto bad_reg;
+}
 return 0;
 }
 bad_reg:
-- 
1.7.5.4

[Qemu-devel] [PATCH 03/11] linux-user: Define TARGET_QEMU_ESIGRETURN for mipsn32

Copied from mips/syscall.h.

Signed-off-by: Ulrich Hecht 
Signed-off-by: Andreas Färber 
---
 linux-user/mipsn32/syscall.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/linux-user/mipsn32/syscall.h b/linux-user/mipsn32/syscall.h
index 4ec506c..ebe98f2 100644
--- a/linux-user/mipsn32/syscall.h
+++ b/linux-user/mipsn32/syscall.h
@@ -218,4 +218,7 @@ struct target_pt_regs {
 
 
 
+/* Nasty hack: define a fake errno value for use by sigreturn. */
+#define TARGET_QEMU_ESIGRETURN 255
+
 #define UNAME_MACHINE "mips64"
-- 
1.7.7

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 06:39 PM, Anthony Liguori wrote:
>
> qemu-test builds a custom guest, entirely from source.  This makes it
> possible to efficiently test non-native architectures.  The tests are
> written for this minimal environment (which is not straight forward to
> do).  This tests will never run on Windows as they are 100% tied to
> their environment.
>
> autotest (let's be clear, there is no such thing as kvm autotest
> anymore) is a framework for executing third party tests.  It's got
> fancy magic to execute in client mode vs. server mode.  There is a
> suite of tests that are integrated in autotest that exercise various
> types of virtualization functionality.  This suite of tests use a
> special config format to determine what they do.
>
> Included in this, is the ability to create a guest from an ISO either
> using step files or via a guest-specific mechanism (kickstart, etc.). 
> The tests are written to be mostly guest agnostic and are therefore
> written in Python in a cross platform way.
>
> There is essentially no overlap between the two and calling kvm
> autotest superior is like calling the Sun superior to the Moon.

Why not extend autotest do the same thing.  Instead of downloading a
fedora iso it would download a kernel tarball and (cross-)build it.

>
>> My main motivation to merge
>> qemu-test and kvm autotest is that I fear that qemu-test will be the
>> only
>> requirement for committing stuff for qemu and developers will be
>> excused from
>> their 'duty' by writing a 50 LOC shell script and assume they done w/
>> testing.
>
> There is no requirement to write autotest tests to get things merged
> into QEMU.  That's is how things are today.
>
> And I don't think there will ever a requirement to write anything that
> isn't merged directly into qemu.git.  I'm not going to hold up merging
> a feature until another project merges something into their tree.

What about virtio features (we used to depend on the kernel, now on the
spec)?  Seabios?

>
> So unless we're going to merge KVM autotest into qemu.git, I don't
> think there's every going to be a requirement to write a KVM autotest
> test in order to get something merged into qemu.git.

Let's consider postcopy live migration being proposed.  In addition to
various unit tests, it also wants an integration test.  So now we need
to write a qemu-test postcopy live migration test, and also autotest
test that tests non-Linux guests, migration under load, with memory
hotplug, etc.

>
> But since autotest is a framework for running third-party tests, it
> seems to make sense for qemu.git to have a test framework that
> autotest can execute.
>
> And since what we call KVM autotest actually tests a heck of a lot
> more than just QEMU, it makes sense for KVM autotest to continue to
> focus on full stack testing where QEMU is but one of the many
> components that it tests.

It might have made sense to split the kvm-testing functionality of
autotest, and have autotest drive that.  We could even have called it
qemu-test.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 07:02 PM, Anthony Liguori wrote:
>
> Those are rare occurrences and have always been a bit awkward.  OTOH,
> we're talking about the critical path of essentially every single
> feature that gets merged into QEMU.
>

Won't that be qtest?

Major features are rare.  Small changes are common.

>> Let's consider postcopy live migration being proposed.  In addition to
>> various unit tests, it also wants an integration test.  So now we need
>> to write a qemu-test postcopy live migration test, and also autotest
>> test that tests non-Linux guests, migration under load, with memory
>> hotplug, etc.
>
> But the integration test is also going to depend on libvirt support
> for the feature.  So how does this all get orchestrated?  kvm-autotest
> merges the test case first, then QEMU merges the support, then
> libvirt?  What about VDSM and ovirt-engine?  Once kvm-autotest starts
> supporting VDSM that's yet another component to deal with.
>
> Realistically, kvm-autotest is going to have to wait for the bits to
> get merged in all of the necessary pieces and then build a test for it
> on their own schedule.

It just has to be posted and reviewed, it doesn't all have to be merged
at the same time (and the qemu merge has to precede the autotest merge)

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RFC v2 2/6] qtest: add support for target-i386 -M pc

On 1 December 2011 18:43, Anthony Liguori  wrote:
> This involves forcing the CPU into the halted state if qtest is enabled and
> replacing the local APIC with the qtest interrupt controller.
>
> It should be pretty straight forward to do the same for other machine types on
> other architectures.

Having to modify every machine type seems to me like a huge red flag that this
is the wrong approach for device level tests. Surely the right thing is to
(a) instantiate the device (b) manipulate it via its publicly exposed interfaces
(ie the memory regions, gpio signals, irqs, etc etc) ?

Alternatively if you're just testing features of the device as it
is wired up on the board then you want something that generates an
image that can just be run on the unmodified QEMU model; that then
lets you cross check by running your tests on real hardware.

-- PMM

Re: [Qemu-devel] [PATCH 2/2] umem: chardevice for kvm postcopy

Thank you for review.

On Thu, Dec 29, 2011 at 01:17:51PM +0200, Avi Kivity wrote:
> > +   default n
> > +   help
> > + User process backed memory driver provides /dev/umem device.
> > + The /dev/umem device is designed for some sort of distributed
> > + shared memory. Especially post-copy live migration with KVM.
> > + When in doubt, say "N".
> > +
> 
> Need documentation of the protocol between the kernel and userspace; not
> just the ioctls, but also how faults are propagated.

Will do.

> 
> > +
> > +struct umem_page_req_list {
> > +   struct list_head list;
> > +   pgoff_t pgoff;
> > +};
> > +
> >
> > +
> > +
> > +static int umem_mark_page_cached(struct umem *umem,
> > +struct umem_page_cached *page_cached)
> > +{
> > +   int ret = 0;
> > +#define PG_MAX ((__u32)32)
> > +   __u64 pgoffs[PG_MAX];
> > +   __u32 nr;
> > +   unsigned long bit;
> > +   bool wake_up_list = false;
> > +
> > +   nr = 0;
> > +   while (nr < page_cached->nr) {
> > +   __u32 todo = min(PG_MAX, (page_cached->nr - nr));
> > +   int i;
> > +
> > +   if (copy_from_user(pgoffs, page_cached->pgoffs + nr,
> > +  sizeof(*pgoffs) * todo)) {
> > +   ret = -EFAULT;
> > +   goto out;
> > +   }
> > +   for (i = 0; i < todo; ++i) {
> > +   if (pgoffs[i] >= umem->pgoff_end) {
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> > +   set_bit(pgoffs[i], umem->cached);
> > +   }
> > +   nr += todo;
> > +   }
> > +
> 
> Probably need an smp_wmb() where.
> 
> > +   spin_lock(&umem->lock);
> > +   bit = 0;
> > +   for (;;) {
> > +   bit = find_next_bit(umem->sync_wait_bitmap, umem->sync_req_max,
> > +   bit);
> > +   if (bit >= umem->sync_req_max)
> > +   break;
> > +   if (test_bit(umem->sync_req[bit], umem->cached))
> > +   wake_up(&umem->page_wait[bit]);
> 
> Why not do this test in the loop above?
> 
> > +   bit++;
> > +   }
> > +
> > +   if (umem->req_list_nr > 0)
> > +   wake_up_list = true;
> > +   spin_unlock(&umem->lock);
> > +
> > +   if (wake_up_list)
> > +   wake_up_all(&umem->req_list_wait);
> > +
> > +out:
> > +   return ret;
> > +}
> > +
> > +
> > +
> > +static void umem_put(struct umem *umem)
> > +{
> > +   int ret;
> > +
> > +   mutex_lock(&umem_list_mutex);
> > +   ret = kref_put(&umem->kref, umem_free);
> > +   if (ret == 0) {
> > +   mutex_unlock(&umem_list_mutex);
> > +   }
> 
> This looks wrong.
> 
> > +}
> > +
> > +
> > +static int umem_create_umem(struct umem_create *create)
> > +{
> > +   int error = 0;
> > +   struct umem *umem = NULL;
> > +   struct vm_area_struct *vma;
> > +   int shmem_fd;
> > +   unsigned long bitmap_bytes;
> > +   unsigned long sync_bitmap_bytes;
> > +   int i;
> > +
> > +   umem = kzalloc(sizeof(*umem), GFP_KERNEL);
> > +   umem->name = create->name;
> > +   kref_init(&umem->kref);
> > +   INIT_LIST_HEAD(&umem->list);
> > +
> > +   mutex_lock(&umem_list_mutex);
> > +   error = umem_add_list(umem);
> > +   if (error) {
> > +   goto out;
> > +   }
> > +
> > +   umem->task = NULL;
> > +   umem->mmapped = false;
> > +   spin_lock_init(&umem->lock);
> > +   umem->size = roundup(create->size, PAGE_SIZE);
> > +   umem->pgoff_end = umem->size >> PAGE_SHIFT;
> > +   init_waitqueue_head(&umem->req_wait);
> > +
> > +   vma = &umem->vma;
> > +   vma->vm_start = 0;
> > +   vma->vm_end = umem->size;
> > +   /* this shmem file is used for temporal buffer for pages
> > +  so it's unlikely that so many pages exists in this shmem file */
> > +   vma->vm_flags = VM_READ | VM_SHARED | VM_NOHUGEPAGE | VM_DONTCOPY |
> > +   VM_DONTEXPAND;
> > +   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> > +   vma->vm_pgoff = 0;
> > +   INIT_LIST_HEAD(&vma->anon_vma_chain);
> > +
> > +   shmem_fd = get_unused_fd();
> > +   if (shmem_fd < 0) {
> > +   error = shmem_fd;
> > +   goto out;
> > +   }
> > +   error = shmem_zero_setup(vma);
> > +   if (error < 0) {
> > +   put_unused_fd(shmem_fd);
> > +   goto out;
> > +   }
> > +   umem->shmem_filp = vma->vm_file;
> > +   get_file(umem->shmem_filp);
> > +   fd_install(shmem_fd, vma->vm_file);
> > +   create->shmem_fd = shmem_fd;
> > +
> > +   create->umem_fd = anon_inode_getfd("umem",
> > +  &umem_fops, umem, O_RDWR);
> > +   if (create->umem_fd < 0) {
> > +   error = create->umem_fd;
> > +   goto out;
> > +   }
> > +
> > +   bitmap_bytes = umem_bitmap_bytes(umem);
> > +   if (bitmap_bytes > PAGE_SIZE) {
> > +   umem->cached = vzalloc(bitmap_bytes);
> > +   umem->faulted = vzalloc(bitmap_bytes);
> > +   } else {
> > +   umem->cached = kzalloc(bitmap_bytes, GFP_KERNEL);
> > +   um

[Qemu-devel] coroutine bug?, was Re: [PATCH] sheepdog: use coroutines

2011-12-29 Thread Christoph Hellwig

On Fri, Dec 23, 2011 at 02:38:50PM +0100, Christoph Hellwig wrote:
> FYI, this causes segfaults when doing large streaming writes when
> running against a sheepdog cluster which:
> 
>   a) has relatively fast SSDs
> 
> and
> 
>   b) uses buffered I/O.
> 
> Unfortunately I can't get a useful backtrace out of gdb.  When running just
> this commit I at least get some debugging messages:
> 
> qemu-system-x86_64: failed to recv a rsp, Socket operation on non-socket
> qemu-system-x86_64: failed to get the header, Socket operation on non-socket
> 
> but on least qemu these don't show up either.

s/least/latest/

Some more debugging.  Just for the call that eventually segfaults s->fd
turns from its normal value (normall 13 for me) into 0.  This is entirely
reproducable in my testing, and given that the sheepdog driver never
assigns to that value except opening the device this seems to point to
an issue in the coroutine code to me.

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

>> I'm surprised: did you test this with upstream qemu?  That codebase
>> doesn't yet throttle writes, and this code path won't execute.  Does
>> it really not reproduce with this patch?
> 
> I think 
> static void handle_output(VirtIODevice *vdev, VirtQueue *vq)
> []
> if (!port->throttled) {
> do_flush_queued_data(port, vq, vdev);
> return;
> 
> makes a difference here, since we will never return the buffer to the guest, 
> no?

And of course this while

static void do_flush_queued_data(VirtIOSerialPort *port, VirtQueue *vq,
 VirtIODevice *vdev)
[...]
while (!port->throttled) {
unsigned int i;

will also prevent further processing, as virtio_serial_throttle_port will 
set port-throttled.

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

On (Thu) 29 Dec 2011 [13:47:43], Christian Borntraeger wrote:
> From: Christian Borntraeger 
> 
> when I tried qemu with -virtio-console pty the guest hangs and attaching on 
> /dev/pts/ does
> not return anything if the attachement is too late.
> Turns out that the console is already throttled and the guest is heavily 
> spinning but get_buf
> never returns the buffer. There seems to be no way for the console to 
> unthrottle the port.
> 
> For the virtio-serial use case we dont want to loose data but for the console 
> case we better
> drop  data instead of "killing" the guest console. If we get 
> chardev->frontend notification
> and a better behaving virtio-console we can revert this fix.
> 
> Signed-off-by: Christian Borntraeger 
> 
> ---
>  hw/virtio-serial-bus.c |   14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> Index: b/hw/virtio-serial-bus.c
> ===
> --- a/hw/virtio-serial-bus.c
> +++ b/hw/virtio-serial-bus.c
> @@ -163,7 +163,19 @@ static void do_flush_queued_data(VirtIOS
>  abort();
>  }
>  if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> -virtio_serial_throttle_port(port, true);

I'm surprised: did you test this with upstream qemu?  That codebase
doesn't yet throttle writes, and this code path won't execute.  Does
it really not reproduce with this patch?

> + /*
> + * this is a temporary check until chardevs can signal to
> + * frontends that they are writable again. This prevents
> + * the console from going into throttled mode (forever)
> + * if virtio-console is connected to a pty without a
> + * listener. Otherwise the guest spins forever.
> + * We can revert this if
> + * 1: chardevs can notify frondends
> + * 2: the guest driver does not spin in these cases
> + */
> +if (!info->is_console) {
> +virtio_serial_throttle_port(port, true);
> +}
>  port->iov_idx = i;
>  if (ret > 0) {
>  port->iov_offset += ret;
> 

Amit

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

On (Thu) 29 Dec 2011 [15:32:14], Christian Borntraeger wrote:
> > port->throttled never becomes true for qemu.  
> 
> Huh? What did I miss below?
> 
> if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> virtio_serial_throttle_port(port, true);

Ah; I see what's happening.  pty_chr_write() returns 0 if a client
isn't yet connected.

This is different from the buggy tcp_chr_write() code, which just
returns 'len', i.e. a successful write.  And since I've only tested
with tcp/unix sockets, I couldn't see why throttling could get
enabled.

Amit

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On 12/29/2011 03:49 PM, Isaku Yamahata wrote:
> > 
> > qemu can have an extra thread that wait4()s the daemon, and relaunch
> > it.  This extra thread would not be blocked by the page fault.  It can
> > keep the fd so it isn't lost.
> > 
> > The unkillability of process A is a security issue; it could be done on
> > purpose.  Is it possible to change umem to sleep with
> > TASK_INTERRUPTIBLE, so it can be killed?
>
> The issue is how to solve the page fault, not whether TASK_INTERRUPTIBLE or
> TASK_UNINTERRUPTIBLE.
> I can think of several options.
> - When daemon X is dead, all page faults are served by zero pages.
> - When daemon X is dead, all page faults are resovled as VM_FAULT_SIGBUS
> - list/reattach: complications. You don't like it
> - other?

Don't resolve the page fault.  It's up to the user/system to make sure
it happens.  qemu can easily do it by watching for the daemon's death
and respawning it.

When the new daemon is started, it can ask the kernel for a list of
pending requests, and service them.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 07:14 PM, Anthony Liguori wrote:
> On 12/29/2011 11:08 AM, Avi Kivity wrote:
>> On 12/29/2011 06:53 PM, Anthony Liguori wrote:
 In what way is your specifically configured kernel's TCP stack better
 than the random distro's kernel's?
>>>
>>>
>>> I firmly believe that with qtest we'll end up eventually building a
>>> libOS to make it easier to write qtest tests.
>>>
>>> Overtime, that libOS will become increasingly complex up until the
>>> point where it approaches something that feels like an actual OS.
>>> Effort spent developing libOS is a cost to building test cases.
>>>
>>> By using Linux and a minimal userspace as our libOS, we can avoid
>>> spending a lot of time building a sophisticated libOS.  If we need
>>> advanced libOS features, we just use qemu-test.  If it's just a matter
>>> of poking some registers on a device along, we just use qtest.
>>
>> Would there be device-level tests in qemu-test?
>
> What is a "device-level" test?
>

A test that tests just one device (or a patch to a single device's
device emulation).

> Take a look at:
>
> http://git.qemu.org/?p=qemu-test.git;a=blob;f=scripts/bin/fingerprint;h=2d4202a826917b16856a2acb4617f623fdc4c0d3;hb=HEAD
>
>
> It's reading BAR0 from any virtio devices to determine the guest
> features exposed.  Yes, it's written in sh :-)  

It would be trivial once libos exists.  And we need libos so we can
-ENOTEST device patches, yes?

> It uses the BAR mappings that sysfs exposes.



-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)


On 12/29/2011 10:07 AM, Dor Laor wrote:

On 12/26/2011 11:05 AM, Avi Kivity wrote:

On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:


btw you can get an additional speedup by enabling x2apic, for
default_send_IPI_mask_logical().


In the host?



In the host, for the guest:

qemu -cpu ...,+x2apic



It seems to me that we should improve our default flags.
So many times users fail to submit the proper huge command-line options that we
require. Honestly, we can't blame them, there are so many flags and so many use
cases its just too hard to get it right for humans.

I propose a basic idea and folks are welcome to discuss it:

1. Improve qemu/kvm defaults
Break the current backward compatibility (but add a --default-
backward-compat-mode) and set better values for:
- rtc slew time


What do you specifically mean?


- cache=none


I'm not sure I see this as a "better default" particularly since O_DIRECT fails 
on certain file systems.  I think we really need to let WCE be toggable from the 
guest and then have a caching mode independent of WCE.  We then need some 
heuristics to only enable cache=off when we know it's safe.



- x2apic, maybe enhance qemu64 or move to -cpu host?


Alex posted a patch for this.  I'm planning on merging it although so far no one 
has chimed up either way.



- aio=native|threads (auto-sense?)


aio=native is unsafe to default because linux-aio is just fubar.  It falls back 
to synchronous I/O if the underlying filesystem doesn't support aio.  There's no 
way in userspace to problem if it's actually supported or not either...



- use virtio devices by default


I don't think this is realistic since appropriately licensed signed virtio 
drivers do not exist for Windows.  (Please note the phrase "appropriately 
licensed signed").



- more?

Different defaults may be picked automatically when TCG|KVM used.

2. External hardening configuration file kept in qemu.git
For non qemu/kvm specific definitions like the io scheduler we
should maintain a script in our tree that sets/sense the optimal
settings of the host kernel (maybe similar one for the guest).


What are "appropriate host settings" and why aren't we suggesting that distros 
and/or upstream just set them by default?


Regards,

Anthony Liguori


HTH,
Dor

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU


On 12/29/2011 11:22 AM, Peter Maydell wrote:

On 29 December 2011 16:36, Avi Kivity  wrote:

Yes; but using Linux limits you to what it exposes (of course Linux
exposes quite a lot, so that's mostly a non issue; but we'll have
counterexamples).


Actually IME Linux is pretty conservative about how it uses devices.
A lot of the ARM device models have gaping holes in their emulation
which we've never needed to fix because Linux simply doesn't use
those features (eg the PL080 DMA controller which doesn't actually
implement DMA!)

I think for devices what would be particularly useful would be
if you can write a (simple) test for something at the register
level, which generates an image which you can run on the real
hardware as well as on QEMU. Then you can confirm that your test
case is correct. Otherwise the tests are just going to bake in the
same assumptions/misconceptions about what the hardware does as
the QEMU model.


I think that could be useful, but it orthogonal to what we need for Test Driven 
Development.


The problem today is that it is very hard to make broad changes in QEMU simply 
because it's so difficult to know whether you're breaking another target.  Look 
at the challenges around merging the memory API.


We need a simple way that a developer can sanity check that they've not broken 
other targets and all of the various devices that we support.




My guess is that a serious attempt at tests covering all the
functionality of a device is probably approximately doubling
the effort required for a device model, incidentally. A
half-hearted attempt probably doesn't buy you much over
automating "boot the guest OS and prod its driver".


Right, but "boot the guest OS and prod its driver" is very useful particularly 
if it can cover all of the various targets we support.


I don't think we should focus much on qtest for non-x86 targets.  I mean, if you 
are interested in it for ARM, fantastic, but I don't think we would mandate it.


For x86, it's reasonable to have stricter requirements on testing, particularly 
for new devices.


FWIW, I expect virtio-scsi to be the first guinea pig here...  I believe Stefan 
has already started looking at writing some qtest based tests for virtio-scsi.


Regards,

Anthony Liguori


-- PMM

Re: [Qemu-devel] [PATCH 3/3] linux-user:Signal handling for MIPS64

Am 29.12.2011 11:58, schrieb Khansa Butt:
> On Wed, Dec 14, 2011 at 9:20 PM, Richard Henderson  wrote:
>> On 12/07/2011 09:25 PM, kha...@kics.edu.pk wrote:
>>> +#if defined(TARGET_MIPS64)
>>> +/* tswapal() do 64 bit swap in case of MIPS64 but
>>> +   we need 32 bit swap as sa_flags is 32 bit */
>>> +k->sa_flags = bswap32(act->sa_flags);
>>> +#else
>>>  k->sa_flags = tswapal(act->sa_flags);
>>> +#endif
>>
>> The condition in syscall_defs.h is TARGET_MIPS, not TARGET_MIPS64.
>> They should match, despite the fact that it doesn't actually matter
>> for the 32-bit abis.
>>
>>>  #elif defined(TARGET_ABI_MIPSN64)
>>>
>>> -# warning signal handling not implemented
>>> +struct target_sigcontext {
>>> +uint32_t   sc_regmask; /* Unused */
>>> +uint32_t   sc_status;
>>
>> There's no reason to duplicate all this code.  Yes, when someone wrote
>> this in the first place, they wrote separate sectons for each mips abi.
>> However, as you can see that huge portions of this block are identical,
>> this was obviously a mistake.
>>
>> Start by changing the original section to #elif defined(TARGET_MIPS)
>> and see what needs changing specifically for the ABIs.  I'm not even
>> sure there are any differences at all.
> 
> The difference lies in setup_frame(). the trampoline function needs
> syscall number
> install_sigtramp(frame->sf_code, TARGET_NR_sigreturn);
> sigreturn is not defined for MIPS64 instead it has only rt_sigreturn.
> I tried with #elif defined(TARGET_MIPS). cross compile the following
> small program and run it on
> qemu-mips64
> #include 
> #include 
> #include 
> #include 
> 
> struct sigaction act;
> 
> void sighandler(int signum, siginfo_t *info, void *ptr)
> {
> printf("Received signal %d\n", signum);
> printf("Signal originates from process %lu\n",(unsigned 
> long)info->si_pid);
> }
> 
> int main()
> {
> printf("I am %lu\n", (unsigned long)getpid());
> 
> memset(&act, 0, sizeof(act));
> 
> act.sa_sigaction = sighandler;
> act.sa_flags = SA_SIGINFO;
> 
> sigaction(SIGILL, &act, NULL);
> 
> // Waiting
> sleep(100);
> 
> return 0;
> }
> 
> and again I found that only install_sigtramp line is needed to be changed.
> keeping  #elif defined(TARGET_MIPS) above signal handling portion, can i use
>  #if defined(TARGET_MIPS64)
>  
> #else
> for install_sigtramp() difference

That's not the only difference - the sigcontext is different, too, for
instance. I hope to get something finished for n32 later today.

Andreas

[Qemu-devel] [RFC PATCH 0/3] tcg: optimize code generation for qemu_ld/st IRs

2011-12-29 Thread YeongKyoon Lee

Title: Samsung Enterprise Portal mySingle


Hi.It is well known that the generated codes from qemu_ld/st IRs to access guest memory are relatively heavy, which are up to 12 instructions for i386 host in TLB hit case.This patch series enhances the code quality of TCG qemu_ld/st IRs by reducing jump and enhancing locality. The main idea is simple and has been already described in the comments in tcg-target.c. It separates slow path, i.e., TLB miss case, and generates it at the end of TB.For example, the generated code from qemu_ld changes as follow.
* Before:(1) TLB check(2) If hit fall through, else jump to TLB miss case (5)(3) TLB hit case: Load value from host memory(4) Jump to next code (6)(5) TLB miss case: call MMU helper(6) ... (next code)
* After:(1) TLB check(2) If hit fall through, else jump to TLB miss case (5)(3) TLB hit case: Load value from host memory(4) ... (next code)...(5) TLB miss case: call MMU helper(6) Return to next code (4)
Following is some performance results.Although there was measurement error, the results was not negligible.
* EEMBC CoreMark (before -> after)  - Guest: i386, Linux (Tizen platform)  - Host: Intel Core2 Quad 2.4GHz, 2GB RAM, Linux  - Results: 1135.6 -> 1179.9 (+3.9%)
* nbench (before -> after)  - Guest: i386, Linux (linux-0.2.img included in QEMU source)  - Host: Intel Core2 Quad 2.4GHz, 2GB RAM, Linux  - Results    . MEMORY INDEX: 1.6782 -> 1.6818 (+0.2%)    . INTEGER INDEX: 1.8258 -> 1.877 (+2.8%)    . FLOATING-POINT INDEX: 0.5944 -> 0.5954 (+0.2%)
 
Yeongkyoon Lee (3): tcg: add extended MMU helper functions tcg: add optimized TCG qemu_ld/st generation configure: add CONFIG_QEMU_LDST_OPTIMIZATION for TCG qemu_ld/st optimization configure |    7 + exec-all.h    |   18 ++- softmmu_template.h    |  123 +++ tcg/i386/tcg-target.c |  392 + tcg/tcg.c |  136 ++ tcg/tcg.h |   45 +- 6 files changed, 656 insertions(+), 65 deletions(-)

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On Thu, Dec 29, 2011 at 03:52:58PM +0200, Avi Kivity wrote:
> On 12/29/2011 03:49 PM, Isaku Yamahata wrote:
> > > 
> > > qemu can have an extra thread that wait4()s the daemon, and relaunch
> > > it.  This extra thread would not be blocked by the page fault.  It can
> > > keep the fd so it isn't lost.
> > > 
> > > The unkillability of process A is a security issue; it could be done on
> > > purpose.  Is it possible to change umem to sleep with
> > > TASK_INTERRUPTIBLE, so it can be killed?
> >
> > The issue is how to solve the page fault, not whether TASK_INTERRUPTIBLE or
> > TASK_UNINTERRUPTIBLE.
> > I can think of several options.
> > - When daemon X is dead, all page faults are served by zero pages.
> > - When daemon X is dead, all page faults are resovled as VM_FAULT_SIGBUS
> > - list/reattach: complications. You don't like it
> > - other?
> 
> Don't resolve the page fault.  It's up to the user/system to make sure
> it happens.  qemu can easily do it by watching for the daemon's death
> and respawning it.
> 
> When the new daemon is started, it can ask the kernel for a list of
> pending requests, and service them.

Great, then we agreed with list/reattach basically.
(Maybe identity scheme needs reconsideration.)
-- 
yamahata

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 06:53 PM, Anthony Liguori wrote:
>> In what way is your specifically configured kernel's TCP stack better
>> than the random distro's kernel's?
>
>
> I firmly believe that with qtest we'll end up eventually building a
> libOS to make it easier to write qtest tests.
>
> Overtime, that libOS will become increasingly complex up until the
> point where it approaches something that feels like an actual OS. 
> Effort spent developing libOS is a cost to building test cases.
>
> By using Linux and a minimal userspace as our libOS, we can avoid
> spending a lot of time building a sophisticated libOS.  If we need
> advanced libOS features, we just use qemu-test.  If it's just a matter
> of poking some registers on a device along, we just use qtest.

Would there be device-level tests in qemu-test?

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On Thu, Dec 29, 2011 at 04:35:36PM +0200, Avi Kivity wrote:
> On 12/29/2011 04:18 PM, Isaku Yamahata wrote:
> > > >
> > > > The issue is how to solve the page fault, not whether 
> > > > TASK_INTERRUPTIBLE or
> > > > TASK_UNINTERRUPTIBLE.
> > > > I can think of several options.
> > > > - When daemon X is dead, all page faults are served by zero pages.
> > > > - When daemon X is dead, all page faults are resovled as VM_FAULT_SIGBUS
> > > > - list/reattach: complications. You don't like it
> > > > - other?
> > > 
> > > Don't resolve the page fault.  It's up to the user/system to make sure
> > > it happens.  qemu can easily do it by watching for the daemon's death
> > > and respawning it.
> > > 
> > > When the new daemon is started, it can ask the kernel for a list of
> > > pending requests, and service them.
> >
> > Great, then we agreed with list/reattach basically.
> > (Maybe identity scheme needs reconsideration.)
> 
> I guess we miscommunicated.  Why is reattach needed?  If you have the
> fd, nothing else is needed.

What if malicious process close the fd and does page fault intentionally?
Unkillable process issue remains.
I think we are talking not only qemu case but also general case.
-- 
yamahata

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 10:36 AM, Avi Kivity wrote:

On 12/29/2011 06:12 PM, Anthony Liguori wrote:

That's why I've also proposed qtest. But having written quite a few
qtest unit tests by now, you hit the limits of this type of testing
pretty quickly.

Can you describe those limits?

I started writing a finger print test. While it's easy to do PCI
enumeration, it gets pretty nasty if you want to actually access BARs
(to read virtio registers)

Why is that? it should be pretty easy to poke values into the BAR registers.

You have to map them which means you need to figure out what the memory layout
looks like. Since there's no BIOS, you need to poke fw_cfg to figure all of
this out and then program the BARs appropriately.

It's definitely non-trivial.

Something else we can do is access the BARs directly. We have APIs to
poke values into mmio, add an api to poke a value into a device's BAR.
Now that each BAR is represented by exactly one memory region, known to
the pci core even if it is not mapped, it should be easy.

and forget about trying to get SMBIOS information as that involves
mucking around with ACPI.

SMBIOS is built by seabios, yes?

I think QEMU actually builds the blob of information and passes the full blob to
SeaBIOS. You could read and parse the blob out of fw_cfg I guess but that's
still pretty sucky. It's a lot nicer to just poke sysfs.

So fingerprinting it should be done
from seabios-test.git. Let's divide it into two problems:

That seems awkward especially since fingerprinting Just Works with qemu-test
already (and it was only 50 lines of shell code!).

- seabios pokes qemu to get information. We should fingerprint this
information to make sure different qemu version can interoperate with
different seabios versions (needed since we migrate the bios along with
the rest of the guest). I'm guessing most of this info is from fwcfg?
We can easily fingerprint it like any other device.
- we need to make sure seabios generates the same tables when using -M.
Here, we're not testing a device, rather we're testing guest code, so it
makes sense to use a guest for this.

However, I don't think it's even necessary. From a quick read of the
manual, SMBIOS is just a set of static tables in memory which are picked
up using a signature. So all we need to do is boot an empty guest, read
its memory, and look for the tables.

Doesn't it sound a whole nicer use linux.git to parse this information for us in
a friendly, easy to consume fashion?

OTOH, it was very simple to write with qemu-test:

http://git.qemu.org/?p=qemu-test.git;a=blob;f=tests/finger-print.sh;h=fc715378a3bbae0b458cc419981c2493d98f5c3d;hb=HEAD

Yes; but using Linux limits you to what it exposes (of course Linux
exposes quite a lot, so that's mostly a non issue; but we'll have
counterexamples).

Maybe. And for those counter examples, we can drill down to qtest. But just
because we may need to do fancy things, it doesn't mean we shouldn't take the
easy approach 95% of the time.

And I ended up finding some long standing bugs in the process:

http://mid.gmane.org/1324305949-20960-2-git-send-email-aligu...@us.ibm.com

It's fairly nasty as it would only show up if doing migration from a
new QEMU with a new guest to a old QEMU.

Yes, good catch.

I think it's a good example of the type of test that I'm targeting at
qemu-test. It's really not interesting to run it across multiple
distro types. But doing it with qtest would be prohibitively hard.

I don't see why. A python library to read pci config should be a couple
of dozens of lines long. Then you iterate over all functions and print
selected registers.

PCI enumeration is easy. It's mapping the bars and then poking other sources of
information that's more challenging.

Everything is doable by writing a libOS but I'd rather just use Linux than
invent a libOS just for testing.

Please review the qtest series. I think it offers a pretty good
approach to writing this style of test. But as I mentioned, you hit
the limits pretty quickly.

I think it's great, it looks like exactly what I wanted, except it's
been delivered on time.

Can you take a look at how interrupts are handled? From what I
gather, the only real limitation of this approach is that we won't be
able to simulate MSI vectors but I don't think that's a huge problem.

I looked at integrating interrupt handling at CPUs itself and that
turned out to be fairly invasive.

You mention in the changelog replacing the APIC. Why can't you do that?

I currently replace the I/O APIC which seems to be limited to 16 IRQs. I think
MSI takes a side channel directly to the local APIC, no?

Think of how new instruction emulations are always accompanied by new

Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on unconnected pty

On 29/12/11 15:56, Amit Shah wrote:
> On (Thu) 29 Dec 2011 [15:32:14], Christian Borntraeger wrote:
>>> port->throttled never becomes true for qemu.  
>>
>> Huh? What did I miss below?
>>
>> if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
>> virtio_serial_throttle_port(port, true);
> 
> 'ret' here is the return value from info->have_data(), which is
> hw/virtio-console.c:flush_buf().  That function returns the value that
> qemu_chr_fe_write() returns, which is qemu-char.c:send_all() for pty,
> tcp, unix sockets.  send_all() just keeps spinning here if it can't
> write, doesn't signal EAGAIN at all (or even a partial write).
> 
> Can you print out the return values of have_data to check what's going
> on?  Maybe you're hitting a case I never hit earlier and throttling
> indeed does get enabled?

ret is 0, see below for the gdb output. send_all does indeed break out of the
loop in case of 0. 

(gdb) bt
#0  do_flush_queued_data (port=0x8130a910, vq=0x813091e0, vdev=0x81309060) at 
/home/cborntra/REPOS/qemu/hw/virtio-serial-bus.c:166
#1  0x8022641e in handle_output (vdev=0x81309060, vq=0x813091e0) at 
/home/cborntra/REPOS/qemu/hw/virtio-serial-bus.c:481
#2  0x8022ac34 in virtio_queue_notify_vq (vq=0x813091e0) at 
/home/cborntra/REPOS/qemu/hw/virtio.c:632
#3  0x8022acc2 in virtio_queue_notify (vdev=0x81309060, n=1) at 
/home/cborntra/REPOS/qemu/hw/virtio.c:638
#4  0x801e7168 in s390_virtio_hypercall (env=0x812f8170, 
mem=2097954816, hypercall=0) at /home/cborntra/REPOS/qemu/hw/s390-virtio.c:86
#5  0x801bf3d4 in handle_hypercall (env=0x812f8170, run=0x2028000) 
at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:270
#6  0x801bf48a in handle_diag (env=0x812f8170, run=0x2028000, 
ipb_code=1280) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:281
#7  0x801bfa3e in handle_instruction (env=0x812f8170, 
run=0x2028000) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:397
#8  0x801bfb76 in handle_intercept (env=0x812f8170) at 
/home/cborntra/REPOS/qemu/target-s390x/kvm.c:420
#9  0x801bfcd2 in kvm_arch_handle_exit (env=0x812f8170, 
run=0x2028000) at /home/cborntra/REPOS/qemu/target-s390x/kvm.c:452
#10 0x801bd774 in kvm_cpu_exec (env=0x812f8170) at 
/home/cborntra/REPOS/qemu/kvm-all.c:1021
#11 0x80181470 in qemu_kvm_cpu_thread_fn (arg=0x812f8170) at 
/home/cborntra/REPOS/qemu/cpus.c:740
#12 0x0243240e in start_thread () from /lib64/libpthread.so.0
#13 0x0255469a in thread_start () from /lib64/libc.so.6
(gdb) print ret
$3 = 0

Re: [Qemu-devel] [PATCH 2/2] umem: chardevice for kvm postcopy

On 12/29/2011 03:26 AM, Isaku Yamahata wrote:
> This is a character device to hook page access.
> The page fault in the area is reported to another user process by
> this chardriver. Then, the process fills the page contents and
> resolves the page fault.
>
>  
> +config UMEM
> +tristate "/dev/umem user process backed memory support"

tab

> + default n
> + help
> +   User process backed memory driver provides /dev/umem device.
> +   The /dev/umem device is designed for some sort of distributed
> +   shared memory. Especially post-copy live migration with KVM.
> +   When in doubt, say "N".
> +

Need documentation of the protocol between the kernel and userspace; not
just the ioctls, but also how faults are propagated.

> +
> +struct umem_page_req_list {
> + struct list_head list;
> + pgoff_t pgoff;
> +};
> +
>
> +
> +
> +static int umem_mark_page_cached(struct umem *umem,
> +  struct umem_page_cached *page_cached)
> +{
> + int ret = 0;
> +#define PG_MAX   ((__u32)32)
> + __u64 pgoffs[PG_MAX];
> + __u32 nr;
> + unsigned long bit;
> + bool wake_up_list = false;
> +
> + nr = 0;
> + while (nr < page_cached->nr) {
> + __u32 todo = min(PG_MAX, (page_cached->nr - nr));
> + int i;
> +
> + if (copy_from_user(pgoffs, page_cached->pgoffs + nr,
> +sizeof(*pgoffs) * todo)) {
> + ret = -EFAULT;
> + goto out;
> + }
> + for (i = 0; i < todo; ++i) {
> + if (pgoffs[i] >= umem->pgoff_end) {
> + ret = -EINVAL;
> + goto out;
> + }
> + set_bit(pgoffs[i], umem->cached);
> + }
> + nr += todo;
> + }
> +

Probably need an smp_wmb() where.

> + spin_lock(&umem->lock);
> + bit = 0;
> + for (;;) {
> + bit = find_next_bit(umem->sync_wait_bitmap, umem->sync_req_max,
> + bit);
> + if (bit >= umem->sync_req_max)
> + break;
> + if (test_bit(umem->sync_req[bit], umem->cached))
> + wake_up(&umem->page_wait[bit]);

Why not do this test in the loop above?

> + bit++;
> + }
> +
> + if (umem->req_list_nr > 0)
> + wake_up_list = true;
> + spin_unlock(&umem->lock);
> +
> + if (wake_up_list)
> + wake_up_all(&umem->req_list_wait);
> +
> +out:
> + return ret;
> +}
> +
> +
> +
> +static void umem_put(struct umem *umem)
> +{
> + int ret;
> +
> + mutex_lock(&umem_list_mutex);
> + ret = kref_put(&umem->kref, umem_free);
> + if (ret == 0) {
> + mutex_unlock(&umem_list_mutex);
> + }

This looks wrong.

> +}
> +
> +
> +static int umem_create_umem(struct umem_create *create)
> +{
> + int error = 0;
> + struct umem *umem = NULL;
> + struct vm_area_struct *vma;
> + int shmem_fd;
> + unsigned long bitmap_bytes;
> + unsigned long sync_bitmap_bytes;
> + int i;
> +
> + umem = kzalloc(sizeof(*umem), GFP_KERNEL);
> + umem->name = create->name;
> + kref_init(&umem->kref);
> + INIT_LIST_HEAD(&umem->list);
> +
> + mutex_lock(&umem_list_mutex);
> + error = umem_add_list(umem);
> + if (error) {
> + goto out;
> + }
> +
> + umem->task = NULL;
> + umem->mmapped = false;
> + spin_lock_init(&umem->lock);
> + umem->size = roundup(create->size, PAGE_SIZE);
> + umem->pgoff_end = umem->size >> PAGE_SHIFT;
> + init_waitqueue_head(&umem->req_wait);
> +
> + vma = &umem->vma;
> + vma->vm_start = 0;
> + vma->vm_end = umem->size;
> + /* this shmem file is used for temporal buffer for pages
> +so it's unlikely that so many pages exists in this shmem file */
> + vma->vm_flags = VM_READ | VM_SHARED | VM_NOHUGEPAGE | VM_DONTCOPY |
> + VM_DONTEXPAND;
> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> + vma->vm_pgoff = 0;
> + INIT_LIST_HEAD(&vma->anon_vma_chain);
> +
> + shmem_fd = get_unused_fd();
> + if (shmem_fd < 0) {
> + error = shmem_fd;
> + goto out;
> + }
> + error = shmem_zero_setup(vma);
> + if (error < 0) {
> + put_unused_fd(shmem_fd);
> + goto out;
> + }
> + umem->shmem_filp = vma->vm_file;
> + get_file(umem->shmem_filp);
> + fd_install(shmem_fd, vma->vm_file);
> + create->shmem_fd = shmem_fd;
> +
> + create->umem_fd = anon_inode_getfd("umem",
> +&umem_fops, umem, O_RDWR);
> + if (create->umem_fd < 0) {
> + error = create->umem_fd;
> + goto out;
> + }
> +
> + bitmap_bytes = umem_bitmap_bytes(umem);
> + if (bitmap_bytes > PAGE_SIZE) {
> + umem->cached = vzalloc(bitmap_bytes)

[Qemu-devel] [PATCH v5 5/5] add L2x0/PL310 cache controller device

From: Rob Herring 

This is just a dummy device for ARM L2 cache controllers, based on the
pl310. The cache type parameter can be defined by a property value
and has a meaningful default.

Signed-off-by: Rob Herring 
Signed-off-by: Mark Langsdorf 
---
Changes from v4
Handling cache_type bits tracked from aux_control in the read function,
not the write function
Changes from v3
Changed default value
Adding tracking of cache_type bits from aux_control
Changes from v2
Reformatted a couple of function definitions to be 80 lines long
Changes from v1
Corrected formatting
Clarified the copyrights
Clarified GPL revision
Clarified model version
Removed hw_error() calls
Added a reset function
Restructed everything as switch/case statements
Added a type cache property

 Makefile.target |1 +
 hw/arm_l2x0.c   |  182 +++
 2 files changed, 183 insertions(+), 0 deletions(-)
 create mode 100644 hw/arm_l2x0.c

diff --git a/Makefile.target b/Makefile.target
index 3261383..db5e44c 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -336,6 +336,7 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o 
arm_timer.o
 obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
 obj-arm-y += versatile_pci.o
 obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
+obj-arm-y += arm_l2x0.o
 obj-arm-y += arm_mptimer.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
 obj-arm-y += pl061.o
diff --git a/hw/arm_l2x0.c b/hw/arm_l2x0.c
new file mode 100644
index 000..ba106f1
--- /dev/null
+++ b/hw/arm_l2x0.c
@@ -0,0 +1,182 @@
+/*
+ * ARM dummy L210, L220, PL310 cache controller.
+ *
+ * Copyright (c) 2010-2012 Calxeda
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or any later version, as published by the Free Software
+ * Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ *
+ */
+
+#include "sysbus.h"
+
+/* L2C-310 r3p2 */
+#define CACHE_ID 0x41c8
+
+typedef struct l2x0_state {
+SysBusDevice busdev;
+MemoryRegion iomem;
+uint32_t cache_type;
+uint32_t ctrl;
+uint32_t aux_ctrl;
+uint32_t data_ctrl;
+uint32_t tag_ctrl;
+uint32_t filter_start;
+uint32_t filter_end;
+} l2x0_state;
+
+static const VMStateDescription vmstate_l2x0 = {
+.name = "l2x0",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(ctrl, l2x0_state),
+VMSTATE_UINT32(aux_ctrl, l2x0_state),
+VMSTATE_UINT32(data_ctrl, l2x0_state),
+VMSTATE_UINT32(tag_ctrl, l2x0_state),
+VMSTATE_UINT32(filter_start, l2x0_state),
+VMSTATE_UINT32(filter_end, l2x0_state),
+VMSTATE_END_OF_LIST()
+}
+};
+
+
+static uint64_t l2x0_priv_read(void *opaque, target_phys_addr_t offset,
+   unsigned size)
+{
+uint32_t cache_data;
+l2x0_state *s = (l2x0_state *)opaque;
+offset &= 0xfff;
+if (offset >= 0x730 && offset < 0x800) {
+return 0; /* cache ops complete */
+}
+switch (offset) {
+case 0:
+return CACHE_ID;
+case 0x4:
+/* aux_ctrl values affect cache_type values */
+cache_data = (s->aux_ctrl & (7 << 17)) >> 15;
+cache_data |= (s->aux_ctrl & (1 << 16)) >> 16;
+return s->cache_type |= (cache_data << 18) | (cache_data << 6);
+case 0x100:
+return s->ctrl;
+case 0x104:
+return s->aux_ctrl;
+case 0x108:
+return s->tag_ctrl;
+case 0x10C:
+return s->data_ctrl;
+case 0xC00:
+return s->filter_start;
+case 0xC04:
+return s->filter_end;
+case 0xF40:
+return 0;
+case 0xF60:
+return 0;
+case 0xF80:
+return 0;
+default:
+fprintf(stderr, "l2x0_priv_read: Bad offset %x\n", (int)offset);
+break;
+}
+return 0;
+}
+
+static void l2x0_priv_write(void *opaque, target_phys_addr_t offset,
+uint64_t value, unsigned size)
+{
+l2x0_state *s = (l2x0_state *)opaque;
+offset &= 0xfff;
+if (offset >= 0x730 && offset < 0x800) {
+/* ignore */
+return;
+}
+switch (offset) {
+case 0x100:
+s->ctrl = value & 1;
+break;
+case 0x104:
+s->aux_ctrl = value;
+break;
+case 0x108:
+s->tag_ctrl = value;
+break;
+case 0x10C:
+s->data_

[Qemu-devel] [PATCH 10/11] linux-user: mipsn32 does not support non-RT signals

Signed-off-by: Andreas Färber 
---
 linux-user/signal.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index bd13f9b..b33f8cb 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2678,7 +2678,7 @@ long do_rt_sigreturn(CPUState *env)
 static void setup_frame(int sig, struct target_sigaction *ka,
target_sigset_t *set, CPUState *env)
 {
-fprintf(stderr, "setup_frame: not implemented\n");
+fprintf(stderr, "setup_frame: not supported in n32 ABI\n");
 }
 
 static void setup_rt_frame(int sig, struct target_sigaction *ka,
@@ -2690,7 +2690,7 @@ static void setup_rt_frame(int sig, struct 
target_sigaction *ka,
 
 long do_sigreturn(CPUState *env)
 {
-fprintf(stderr, "do_sigreturn: not implemented\n");
+fprintf(stderr, "do_sigreturn: not supported in n32 ABI\n");
 return -TARGET_ENOSYS;
 }
 
-- 
1.7.7

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On Thu, Dec 29, 2011 at 02:55:42PM +0200, Avi Kivity wrote:
> On 12/29/2011 02:39 PM, Isaku Yamahata wrote:
> > > > ioctl commands:
> > > >
> > > > UMEM_DEV_CRATE_UMEM: create umem device for qemu
> > > > UMEM_DEV_LIST: list created umem devices
> > > > UMEM_DEV_REATTACH: re-attach the created umem device
> > > >   UMEM_DEV_LIST and UMEM_DEV_REATTACH are used when
> > > >   the process that services page fault disappears or 
> > > > get stack.
> > > >   Then, administrator can list the umem devices and 
> > > > unblock
> > > >   the process which is waiting for page.
> > > 
> > > Ah, I asked about this in my patch comments.  I think this is done
> > > better by using SCM_RIGHTS to pass fds along, or asking qemu to launch a
> > > new process.
> >
> > Can you please elaborate? I think those ways you are suggesting doesn't 
> > solve
> > the issue. Let me clarify the problem.
> >
> >   process A (typically incoming qemu)
> >  |
> >  | mmap("/dev/umem") and access those pages triggering page faults
> >  | (the file descriptor might be closed after mmap() before page faults)
> >  |
> >  V
> >/dev/umem
> >  ^
> >  |
> >  |
> >daemon X resolving page faults triggered by process A
> >(typically this daemon forked from incoming qemu:process A)
> >
> > If daemon X disappears accidentally, there is no one that resolves
> > page faults of process A. At this moment process A is blocked due to page
> > fault. There is no file descriptor available corresponding to the VMA.
> > Here there is no way to kill process A, but system reboot.
> 
> qemu can have an extra thread that wait4()s the daemon, and relaunch
> it.  This extra thread would not be blocked by the page fault.  It can
> keep the fd so it isn't lost.
> 
> The unkillability of process A is a security issue; it could be done on
> purpose.  Is it possible to change umem to sleep with
> TASK_INTERRUPTIBLE, so it can be killed?

The issue is how to solve the page fault, not whether TASK_INTERRUPTIBLE or
TASK_UNINTERRUPTIBLE.
I can think of several options.
- When daemon X is dead, all page faults are served by zero pages.
- When daemon X is dead, all page faults are resovled as VM_FAULT_SIGBUS
- list/reattach: complications. You don't like it
- other?


> > > Introducing a global namespace has a lot of complications attached.
> > > 
> > > >
> > > > UMEM_GET_PAGE_REQUEST: retrieve page fault of qemu process
> > > > UMEM_MARK_PAGE_CACHED: mark the specified pages pulled from the source
> > > >for daemon
> > > >
> > > > UMEM_MAKE_VMA_ANONYMOUS: make the specified vma in the qemu process
> > > >  This is _NOT_ implemented yet.
> > > >  anonymous I'm not sure whether this can be 
> > > > implemented
> > > >  or not.
> > > 
> > > How do we find out?  This is fairly important, stuff like transparent
> > > hugepages and ksm only works on anonymous memory.
> >
> > I agree that this is important.
> > At KVM-forum 2011, Andrea said THP and KSM works with non-anonymous VMA.
> > (Or at lease he'll look into those stuff. My memory is vague, though.
> >  Please correct me if I'm wrong)
> 
> += Andrea (who can also provide feedback on umem in general)
> 
> -- 
> error compiling committee.c: too many arguments to function
> 

-- 
yamahata

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On 12/29/2011 04:18 PM, Isaku Yamahata wrote:
> > >
> > > The issue is how to solve the page fault, not whether TASK_INTERRUPTIBLE 
> > > or
> > > TASK_UNINTERRUPTIBLE.
> > > I can think of several options.
> > > - When daemon X is dead, all page faults are served by zero pages.
> > > - When daemon X is dead, all page faults are resovled as VM_FAULT_SIGBUS
> > > - list/reattach: complications. You don't like it
> > > - other?
> > 
> > Don't resolve the page fault.  It's up to the user/system to make sure
> > it happens.  qemu can easily do it by watching for the daemon's death
> > and respawning it.
> > 
> > When the new daemon is started, it can ask the kernel for a list of
> > pending requests, and service them.
>
> Great, then we agreed with list/reattach basically.
> (Maybe identity scheme needs reconsideration.)

I guess we miscommunicated.  Why is reattach needed?  If you have the
fd, nothing else is needed.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy

On 12/29/2011 03:26 AM, Isaku Yamahata wrote:
> This is Linux kernel driver for qemu/kvm postcopy live migration.
> This is used by qemu/kvm postcopy live migration patch.
>
> TODO:
> - Consider FUSE/CUSE option
>   So far several mmap patches for FUSE/CUSE are floating around. (their
>   purpose isn't different from our purpose, though). They haven't merged
>   into the upstream yet.
>   The driver specific part in qemu patches is modularized. So I expect it
>   wouldn't be difficult to switch kernel driver to CUSE based driver.

It would be good to get more input about this, please involve lkml and
the FUSE/CUSE people.

> ioctl commands:
>
> UMEM_DEV_CRATE_UMEM: create umem device for qemu
> UMEM_DEV_LIST: list created umem devices
> UMEM_DEV_REATTACH: re-attach the created umem device
> UMEM_DEV_LIST and UMEM_DEV_REATTACH are used when
> the process that services page fault disappears or get stack.
> Then, administrator can list the umem devices and unblock
> the process which is waiting for page.

Ah, I asked about this in my patch comments.  I think this is done
better by using SCM_RIGHTS to pass fds along, or asking qemu to launch a
new process.

Introducing a global namespace has a lot of complications attached.

>
> UMEM_GET_PAGE_REQUEST: retrieve page fault of qemu process
> UMEM_MARK_PAGE_CACHED: mark the specified pages pulled from the source
>for daemon
>
> UMEM_MAKE_VMA_ANONYMOUS: make the specified vma in the qemu process
>This is _NOT_ implemented yet.
>  anonymous I'm not sure whether this can be 
> implemented
>  or not.

How do we find out?  This is fairly important, stuff like transparent
hugepages and ksm only works on anonymous memory.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

On 12/29/2011 07:49 PM, Peter Maydell wrote:
> On 29 December 2011 17:26, Avi Kivity  wrote:
> > On 12/29/2011 07:22 PM, Peter Maydell wrote:
> >> My guess is that a serious attempt at tests covering all the
> >> functionality of a device is probably approximately doubling
> >> the effort required for a device model, incidentally. A
> >> half-hearted attempt probably doesn't buy you much over
> >> automating "boot the guest OS and prod its driver".
> >
> > Agreed.
>
> The next obvious question is: are we going to make a serious attempt?
> (For instance, in a hypothetical tests-required world, would we
> tell those nice folks from Samsung "no you can't land your
> Exynos patches unless you write 9000+ lines of test cases" ?

Yes.

> I suspect that if we set the bar for new board and device models
> that high then the result will largely be that we don't in fact
> get new board or device models.)

If just doubles the effort, I disagree.

Even if that turns out to be the case, it's fine.  Better to have a few
good devices than dozens of bad ones.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [Bug 818673] Re: virtio: trying to map MMIO memory

2011-12-29 Thread Arequipeno

I've been dealing with this bug for some time on Fedora.  Until
recently, I was using the VirtIO drivers from RHEV 2.2, which don't
suffer from this problem.  As of Fedora 16, however, that isn't an
option, because they cause the guest to blue-screen early in the boot
process.

So ... I've been doing some more testing with the following setup:

  Host:
Intel DQ67SW motherboard with Q67 chipset (including IOMMU)
BIOS version SWQ6710H.86A.0050.2011.0401.1409 (release date 04/01/2011)
Intel Core i7 2600, 4-cores, 8 threads, 3.4 GHz
16GB memory
Fedora 15 64-bit, fully updated including updates-testing repo
  qemu-kvm-0.14.0-8.fc15.x86_64
  libvirt-0.8.8-7.fc15.x86_64
  kernel-2.6.41.6-1.fc15.x86_64

  Guest:
Windows 7 Professional 32-bit, fully updated
2 VCPUs
3.5GB memory
Red Hat VirtIO Ethernet Adapter driver version 6.0.209.605 (9/20/2010)
Red Hat VirtIO SCSI Controller driver version 6.0.0.10 (9/20/2010)
(No VirtIO serial ports or channels defined)

(The VirtIO drivers are from http://alt.fedoraproject.org/pub/alt
/virtio-win/latest/images/.)

I have determined that disabling the Intel IOMMU has no effect; the
problem still occurs.

Perhaps more interestingly, it seems that the problem only occurs when I
am using the VirtIO SCSI *and* the VirtIO Ethernet drivers.  It seems
that the problem does not occur if I only use one of the drivers; an IDE
disk with a VirtIO NIC seems to be stable, as does a VirtIO disk with an
e1000 NIC.

Now to the big question ... what the heck can be done to get this problem 
fixed?  I hope that everyone agrees that it's totally unacceptable for a 
problem like this to sit unfixed for so long.  I am more than willing to test 
any patches, enable
debugging, etc.; just tell me what to do.

Thanks!

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

Title:
  virtio: trying to map MMIO memory

Status in QEMU:
  New

Bug description:
  Qemu host is Core i7, running Linux.  Guest is Windows XP sp3.
  Often, qemu will crash shortly after starting (1-5 minutes) with a statement 
"qemu-system-x86_64: virtio: trying to map MMIO memory"
  This has occured with qemu-kvm 0.14, qemu-kvm 0.14.1, qemu-0.15.0-rc0 and 
qemu 0.15.0-rc1.
  Qemu is started as such:
  qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid 
-drive file=/home/rick/qemu/hds/wxp.raw,if=virtio -m 768 -name WinXP -net 
nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial 
-chardev spicevmc,name=vdagent,id=vdagent -device 
virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice 
port=1234,disable-ticketing -daemonize -monitor 
telnet:localhost:12341,server,nowait
  The WXP guest has virtio 1.1.16 drivers for net and scsi, and the most 
current spice binaries from spice-space.org.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/818673/+subscriptions

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU