On Fri, Nov 8, 2013 at 12:19 PM, Liu ping fan <kernelfans@xxxxxxxxx> wrote: > On Fri, Nov 8, 2013 at 11:10 AM, Alexander Graf <agraf@xxxxxxx> wrote: >> >> On 08.11.2013, at 03:44, Liu Ping Fan <kernelfans@xxxxxxxxx> wrote: >> >>> syscall is a very common behavior inside guest, and this patch >>> optimizes the path for the emulation of BOOK3S_INTERRUPT_SYSCALL, >>> so hypervisor can return to guest without heavy exit, i.e, no need >>> to swap TLB, HTAB,.. etc >> >> The syscall exit you touch here only happens when you do an sc > 0 with MSR_PR set inside the guest. The only case you realistically see this is when you run PR KVM inside of an HV KVM guest. >> > Maybe I misunderstood the ISA spec, but refer for "6.5.14 System Call > Interrupt", no description about the MSR_PR when sc trigger a syscall > interrupt. So I think, guest application "sc 0" will also fall to the > kernel who owns hypervisor mode. Am I right? > Some further comment: I think the essential of the problem is whether we switch RMA from guest to HV when interrupts raise. DSI/ISI will be redirected to HDSI and RMA switch. But what about SYSCALL, and DEC, external interrupt, ...etc? >> I don't think we should optimize for that case. Instead, we should rather try to not bounce to the 1st hypervisor in the first place in that scenario :). >> > Sorry, but just want to make clear about the idiom: 0 -> kernel run > with NV, and 1st -> kernel run on HV-KVM and provide PR-KVM to up > layer? Right? > > When you say "try to not bounce to the 1st hypervisor ", what is the > exact meaning and how can we achieve this? I am a quite newer on > powerpc, and hope that I can get more clear figure about it :) > Thanks Pingfan -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
