Guest reboot interface

Guest reboot interface

[Liu Yu-B13201]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 654 bytes --]


Hi all,

When guest reboot, it's better to reset status by qemu, and then sync them back to kvm
However as you know there's no BOOKE mmu emulation in qemu,
So that qemu cannot directly reset BOOKE TLB.
Moreover a lot SPR registers also cannot be reset by qemu.

As a workaround, we need a interface that qemu can notify kvm to reset the status.
My question is, what should the interface be?
Looks like there's no alike interface in other archs.
Should we define a ioctl command number only used by BOOKE or powerpc?


Thanks,
Yu
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¤¾oé¥ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Guest reboot interface

[Alexander Graf]

On 07.01.2011, at 13:08, Liu Yu-B13201 wrote:

> 
> Hi all,
> 
> When guest reboot, it's better to reset status by qemu, and then sync them back to kvm
> However as you know there's no BOOKE mmu emulation in qemu,
> So that qemu cannot directly reset BOOKE TLB.
> Moreover a lot SPR registers also cannot be reset by qemu.
> 
> As a workaround, we need a interface that qemu can notify kvm to reset the status.
> My question is, what should the interface be?
> Looks like there's no alike interface in other archs.
> Should we define a ioctl command number only used by BOOKE or powerpc?

Wouldn't it make more sense to just fake-implement the registers (SPRs and unused TLB) and sync that back on reset? You don't have to implement the actual mmu logic, but that keeps things at the same place at least.


Alex

Re: Guest reboot interface

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Am 07.01.2011 13:40, Alexander Graf wrote:
> 
> On 07.01.2011, at 13:08, Liu Yu-B13201 wrote:
> 
>>
>> Hi all,
>>
>> When guest reboot, it's better to reset status by qemu, and then sync them back to kvm
>> However as you know there's no BOOKE mmu emulation in qemu,
>> So that qemu cannot directly reset BOOKE TLB.
>> Moreover a lot SPR registers also cannot be reset by qemu.
>>
>> As a workaround, we need a interface that qemu can notify kvm to reset the status.
>> My question is, what should the interface be?
>> Looks like there's no alike interface in other archs.
>> Should we define a ioctl command number only used by BOOKE or powerpc?
> 
> Wouldn't it make more sense to just fake-implement the registers (SPRs and unused TLB) and sync that back on reset? You don't have to implement the actual mmu logic, but that keeps things at the same place at least.
> 

This is how it's done on x86, and it's the preferred way. There will
never be such things as KVM_IOCTL_RESET.

BTW, isn't the TLB state relevant for vmsave/restore? Then it should be
made accessible for user space anyway.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: Guest reboot interface

[Scott Wood]

On Fri, 7 Jan 2011 16:38:35 +0100
Jan Kiszka <jan.kiszka@web.de> wrote:

> Am 07.01.2011 13:40, Alexander Graf wrote:
> > 
> > On 07.01.2011, at 13:08, Liu Yu-B13201 wrote:
> > 
> >>
> >> Hi all,
> >>
> >> When guest reboot, it's better to reset status by qemu, and then sync them back to kvm
> >> However as you know there's no BOOKE mmu emulation in qemu,
> >> So that qemu cannot directly reset BOOKE TLB.
> >> Moreover a lot SPR registers also cannot be reset by qemu.
> >>
> >> As a workaround, we need a interface that qemu can notify kvm to reset the status.
> >> My question is, what should the interface be?
> >> Looks like there's no alike interface in other archs.
> >> Should we define a ioctl command number only used by BOOKE or powerpc?
> > 
> > Wouldn't it make more sense to just fake-implement the registers (SPRs and unused TLB) and sync that back on reset? You don't have to implement the actual mmu logic, but that keeps things at the same place at least.
> > 
> 
> This is how it's done on x86, and it's the preferred way. There will
> never be such things as KVM_IOCTL_RESET.
> 
> BTW, isn't the TLB state relevant for vmsave/restore? Then it should be
> made accessible for user space anyway.

It'll also be helpful for debugging, and for giving Qemu more control
over how the OS is loaded -- having guest memory start somewhere other
than zero is useful when doing DMA without an IOMMU, and there'll have
to be a TLB entry pointing up there on entry.

-Scott