On 11/02/2009 10:23 PM, Alexander Graf wrote:
Any progress on the patch? This is really important to make KVM work
properly on S390. I'd even go as far as suggesting it for linux-stable.
I forgot all about it, sorry. Marcelo, can you commit it?
--
error compiling committee.c: too many ar
Carsten Otte wrote:
> Avi Kivity wrote:
>> So why not do it for this instruction as well? Instead of updating
>> the psw, return a success/error code and let the kernel update psw.
> It's not a single instruction, but a set of reasons we need the psw in
> userspace:
> - for logging the instruction
Avi Kivity wrote:
So why not do it for this instruction as well? Instead of updating the
psw, return a success/error code and let the kernel update psw.
It's not a single instruction, but a set of reasons we need the psw in
userspace:
- for logging the instruction address on exits
- to check i
On 10/22/2009 12:43 PM, Carsten Otte wrote:
Avi Kivity wrote:
On x86 we avoid emulating instructions in userspace. Instead the
kernel requests userspace to do something (triggered by the
instruction), and the kernel does anything which might be implied by
the instruction (like copying the res
Avi Kivity wrote:
On x86 we avoid emulating instructions in userspace. Instead the kernel
requests userspace to do something (triggered by the instruction), and
the kernel does anything which might be implied by the instruction (like
copying the result into a register, or updating pc).
An ex
On 10/22/2009 12:20 PM, Carsten Otte wrote:
Avi Kivity wrote:
gdb is hardly performance critical. Is that the only reason for the
change?
Right, gdb is not performance critical. gdb is the reason for moving
it out of the union, performance is the reason for having it in
kvm_run at all.
There'
On 10/22/2009 12:22 PM, Carsten Otte wrote:
Avi Kivity wrote:
Right, but why? x86 qemu doesn't care about either pc or eflags
(with in-kernel irqchip, which s390 essentially is).
For different reasons. Most prominent for setting the condition code,
which is a sideband result of most instructio
Avi Kivity wrote:
Right, but why? x86 qemu doesn't care about either pc or eflags (with
in-kernel irqchip, which s390 essentially is).
For different reasons. Most prominent for setting the condition code,
which is a sideband result of most instructions that indicates whether or
not the instruct
Avi Kivity wrote:
gdb is hardly performance critical. Is that the only reason for the
change?
Right, gdb is not performance critical. gdb is the reason for moving it
out of the union, performance is the reason for having it in kvm_run at all.
There's only more reason to it: with a little tweaki
On 22.10.2009, at 12:03, Avi Kivity wrote:
On 10/22/2009 11:55 AM, Alexander Graf wrote:
On 22.10.2009, at 11:53, Avi Kivity wrote:
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the
structure?
Best to put it after the union (and as a
On 10/22/2009 11:55 AM, Alexander Graf wrote:
On 22.10.2009, at 11:53, Avi Kivity wrote:
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the structure?
Best to put it after the union (and as a copy, so userspace that
expects the previous l
On 10/22/2009 11:18 AM, Carsten Otte wrote:
I'd also appreciate an explanation of what this is all about.
The processor status word does contain various bits about the CPU's
state, such as interrupt mask bits, current address space, and the
current instruction address. The status is kept in t
On 22.10.2009, at 11:55, Alexander Graf wrote:
PSW = (eflags << 32) | pc;
Eh - 64 of course. The PSW is 128 bits.
Alex
On 22.10.2009, at 11:53, Avi Kivity wrote:
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the structure?
Best to put it after the union (and as a copy, so userspace that
expects the previous location still works). If you're reading it
On 10/22/2009 11:11 AM, Alexander Graf wrote:
Doesn't this break backward compatibility by changing the structure?
Best to put it after the union (and as a copy, so userspace that
expects the previous location still works). If you're reading it
from the kernel, also need a way to tell the ker
Avi Kivity wrote:
@@ -116,6 +117,11 @@
__u64 cr8;
__u64 apic_base;
+#ifdef CONFIG_S390
+/* the processor status word for s390 */
+__u64 psw_mask; /* psw upper half */
+__u64 psw_addr; /* psw lower half */
+#endif
Doesn't this break backward compatibility by changing the str
On 22.10.2009, at 11:08, Avi Kivity wrote:
On 10/20/2009 06:40 PM, Carsten Otte wrote:
This patch moves s390 processor status word into the base kvm_run
struct and keeps it up-to date on all userspace exits.
+#include
#include
#include
#include
Not needed.
@@ -116,6 +117,11 @@
__u
On 10/20/2009 06:40 PM, Carsten Otte wrote:
This patch moves s390 processor status word into the base kvm_run
struct and keeps it up-to date on all userspace exits.
+#include
#include
#include
#include
Not needed.
@@ -116,6 +117,11 @@
__u64 cr8;
__u64 apic_base;
+#ifdef CONFIG_
Alexander Graf wrote:
This is the resulting code. Please comment on things you like and also on the
ones you don't :-).
Looks fantastic now. Whole series:
Acked-by: Carsten Otte
On 21.10.2009, at 10:18, Carsten Otte wrote:
Alexander Graf wrote:
Either we take the psw in on x86 too or we #ifdef out the x86
specific stuff on s390.
Good idea, I'll #ifndef CONFIG_S390 the x86 specifics while we're at
it.
Maybe better #if defined(TARGET_X86) || defined(TARGET_IA64). W
Alexander Graf wrote:
Either we take the psw in on x86 too or we #ifdef out the x86 specific
stuff on s390.
Good idea, I'll #ifndef CONFIG_S390 the x86 specifics while we're at it.
On 20.10.2009, at 18:40, Carsten Otte wrote:
Alexander Graf wrote:
This is the resulting code. Please comment on things you like and
also on the
ones you don't :-).
I've reviewed and tested it, great work Alex :-)
Also to actually run this code you need a patch for an ugly bug in
the ker
On 20.10.2009, at 18:40, Carsten Otte wrote:
Alexander Graf wrote:
This is the resulting code. Please comment on things you like and
also on the
ones you don't :-).
I've reviewed and tested it, great work Alex :-)
Also to actually run this code you need a patch for an ugly bug in
the ker
On 20.10.2009, at 18:40, Carsten Otte wrote:
Alexander Graf wrote:
This is the resulting code. Please comment on things you like and
also on the
ones you don't :-).
I've reviewed and tested it, great work Alex :-)
Thanks :-).
Also to actually run this code you need a patch for an ugly bu
Alexander Graf wrote:
This is the resulting code. Please comment on things you like and also on the
ones you don't :-).
I've reviewed and tested it, great work Alex :-)
Also to actually run this code you need a patch for an ugly bug in the kernel
module: http://alex.csgraf.de/psw.patch
Well, i
25 matches
Mail list logo
