Aurelien Jarno wrote:
I am not fully comfortable introducing a binary firmware based on a
patch posted on a website. I see two options:
- Get your patch merged into ZIPL, so that we can build the firmware
directly from the ZIPL sources
- Add the patch to the pc-bios/ directory
Looks like we'll
Blue Swirl wrote:
The translation block (TB) refers to a block of host instructions,
translated from some block of target instructions under some
assumptions. The assumptions used when translating (for example, user
vs supervisor mode in the CPU state) are recorded to TB flags. If the
CPU state c
Alexander Graf wrote:
I don't know what psw.mask represent, but it may be wrong. It should be
a way to identify which TB can be reused, that is they have been
generated in the same CPU mode.
psw.mask is rougly the same as RFLAGS, cr0 and cr4 on x86_64 combined. So IMHO
it looked like a pretty
Aurelien Jarno wrote:
+static inline int cpu_mmu_index (CPUState *env)
+{
+/* XXX: Currently we don't implement virtual memory */
+return 0;
Is it correct? It means that memory access will aways be kernel memory
accesses. IIRC, even with KVM enabled, softmmu accesses are possible in
som
Alexander Graf wrote:
For the technical reason I hope Carsten can provide some insight.
As for the implementation reason - S390 KVM (the kernel part) doesn't do
memslots properly :-).
I'm sorry, I cannot comment on that :-(.
Arnd Bergmann wrote:
Can't you just leave it out for this release? Early printk is great
for debugging, but not essential if you just want to run a guest
as long as you get it past the virtio init phase.
The upstream kernel assumes to have this hypercall available when
running on kvm. You won't
Hannes Reinecke wrote:
So back to the zipl question, it might be an idea to support initially
the SCSI disk layout only. This has the advantage of being far simpler
as the DASD disk layout and should be pretty straightforward to handle.
Issue is, the dasd disk layout is made for dasds. For eckd,
Anthony Liguori wrote:
I do, that's why I brought it up. AFAICT, there hasn't been a lot of
progress with kboot. Carsten or Alex would probably know better if
anyone is actually using it on s390s.
I fail to see how kboot would solve this problem.
Anthony Liguori wrote:
Oh, that's bad :-)
That should really be it's own character device. We don't really have a
way to connect two character devices like that. Maybe muxing?
It will be a character device, once the device tree is initialized.
Better ideas are welcome, just keep in mind basi
Anthony Liguori wrote:
Can't you just use kboot?
Use a kernel loader to load the kboot module/initrd, include kboot as
our firmware, then let kboot do the magic to launch the real linux
kernel from disk.
Hehe, and how would you load that initial kernel if you don't have bios?
No matter what,
Anthony Liguori wrote:
What is this used for?
On x86 the kernel uses bios output for early prints. We don't have bios
and do therefore need to bring up a console device as early as possible
so that we can see kernel panics during I/O subsystem detection/startup.
All s390 console devices do sup
Anthony Liguori wrote:
This is a bit unfortunate. Wouldn't it be better to write a custom
version of zipl that ran in the guest?
This is like implementing grub in qemu (or pygrub in Xen). The level of
security exposure this introduces is really scary.
Oh that's really the wrong way to see it
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
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
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
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
Anthony Liguori wrote:
However, an ugly #ifdef immediately tells someone, oh, s390 kvm needs
this terrible hack, so let's keep bugging those guys to eliminate the
need for that.
/me moves cleaning up memslot handling a little further up the prio
list. I fear it still won't make it to queue head
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
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.
t
sense if Avi picks this patch and you adopt your series to it. This way
the user interface of the kvm module works for both kuli and qemu.
This patch moves s390 processor status word into the base kvm_run
struct and keeps it up-to date on all userspace exits.
Signed-off-by: Carsten Otte
Alexander Graf wrote:
++static int s390_cpu_initial_reset(CPUState *env)
+{
+/* XXX */
+fprintf(stderr, "XXX SIGP init\n");
+return -1;
+}
That one will really break SMP. Most of the initial reset is handled
in-kernel for your convenience, therefore please think about using Kuli
a
Alexander Graf wrote:
S390 requires vmas for guests to be < 256 GB. So we need to directly export
mmaps "try to use this vma as start address" feature to not accidently get
over that limit.
Hmmh, now that x86 has solved all the problems we should probably move
away from using the same page table
23 matches
Mail list logo
