| Message ID | 1253631112-26124-3-git-send-email-gleb@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/22/2009 05:51 PM, Gleb Natapov wrote: > Each caller of the function already calls it. > > Signed-off-by: Gleb Natapov<gleb@redhat.com> > --- > hw/apic.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/hw/apic.c b/hw/apic.c > index 3a2e128..a9d1fb8 100644 > --- a/hw/apic.c > +++ b/hw/apic.c > @@ -488,7 +488,6 @@ void apic_init_reset(CPUState *env) > if (!s) > return; > > - cpu_synchronize_state(env); > s->tpr = 0; > s->spurious_vec = 0xff; > s->log_dest = 0; > Still, it's safer to live this in.
Avi Kivity wrote: > On 09/22/2009 05:51 PM, Gleb Natapov wrote: >> Each caller of the function already calls it. >> >> Signed-off-by: Gleb Natapov<gleb@redhat.com> >> --- >> hw/apic.c | 1 - >> 1 files changed, 0 insertions(+), 1 deletions(-) >> >> diff --git a/hw/apic.c b/hw/apic.c >> index 3a2e128..a9d1fb8 100644 >> --- a/hw/apic.c >> +++ b/hw/apic.c >> @@ -488,7 +488,6 @@ void apic_init_reset(CPUState *env) >> if (!s) >> return; >> >> - cpu_synchronize_state(env); >> s->tpr = 0; >> s->spurious_vec = 0xff; >> s->log_dest = 0; >> > > Still, it's safer to live this in. > Yet another diff to upstream... It's really time to stabilize this still a bit fuzzy register sync model, also in qemu-kvm. If you think we need it, let us push it upstream - with a sound explanation, and maybe even with more sync points for the sake of consistency. Jan
On 09/23/2009 06:07 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 09/22/2009 05:51 PM, Gleb Natapov wrote: >> >>> Each caller of the function already calls it. >>> >>> Signed-off-by: Gleb Natapov<gleb@redhat.com> >>> --- >>> hw/apic.c | 1 - >>> 1 files changed, 0 insertions(+), 1 deletions(-) >>> >>> diff --git a/hw/apic.c b/hw/apic.c >>> index 3a2e128..a9d1fb8 100644 >>> --- a/hw/apic.c >>> +++ b/hw/apic.c >>> @@ -488,7 +488,6 @@ void apic_init_reset(CPUState *env) >>> if (!s) >>> return; >>> >>> - cpu_synchronize_state(env); >>> s->tpr = 0; >>> s->spurious_vec = 0xff; >>> s->log_dest = 0; >>> >>> >> Still, it's safer to live this in. >> >> > Yet another diff to upstream... > > It's really time to stabilize this still a bit fuzzy register sync > model, also in qemu-kvm. If you think we need it, let us push it > upstream - with a sound explanation, and maybe even with more sync > points for the sake of consistency. > > Functions calling each other in the same subsystem can rely on callers calling cpu_synchronize_state(). Across subsystems, that's another matter, exported functions should try not to rely on implementation details of their callers. (You might argue that the apic is not separate subsystem wrt an x86 cpu, and I'm not sure I have a counterargument)
Avi Kivity wrote: > On 09/23/2009 06:07 PM, Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> On 09/22/2009 05:51 PM, Gleb Natapov wrote: >>> >>>> Each caller of the function already calls it. >>>> >>>> Signed-off-by: Gleb Natapov<gleb@redhat.com> >>>> --- >>>> hw/apic.c | 1 - >>>> 1 files changed, 0 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/hw/apic.c b/hw/apic.c >>>> index 3a2e128..a9d1fb8 100644 >>>> --- a/hw/apic.c >>>> +++ b/hw/apic.c >>>> @@ -488,7 +488,6 @@ void apic_init_reset(CPUState *env) >>>> if (!s) >>>> return; >>>> >>>> - cpu_synchronize_state(env); >>>> s->tpr = 0; >>>> s->spurious_vec = 0xff; >>>> s->log_dest = 0; >>>> >>>> >>> Still, it's safer to live this in. >>> >>> >> Yet another diff to upstream... >> >> It's really time to stabilize this still a bit fuzzy register sync >> model, also in qemu-kvm. If you think we need it, let us push it >> upstream - with a sound explanation, and maybe even with more sync >> points for the sake of consistency. >> >> > > Functions calling each other in the same subsystem can rely on callers > calling cpu_synchronize_state(). Across subsystems, that's another > matter, exported functions should try not to rely on implementation > details of their callers. > > (You might argue that the apic is not separate subsystem wrt an x86 cpu, > and I'm not sure I have a counterargument) > I do accept this argument. It's just that my feeling is that we are lacking proper review of the required call sites of cpu_sychronize_state and rather put it where some regression popped up (and that only in qemu-kvm...). The new rule is: Synchronize the states before accessing registers (or in-kernel devices) the first time after a vmexit to user space. But, e.g., I do not see where we do this on CPU reset. Jan
On 09/23/2009 06:45 PM, Jan Kiszka wrote: >> Functions calling each other in the same subsystem can rely on callers >> calling cpu_synchronize_state(). Across subsystems, that's another >> matter, exported functions should try not to rely on implementation >> details of their callers. >> >> (You might argue that the apic is not separate subsystem wrt an x86 cpu, >> and I'm not sure I have a counterargument) >> >> > I do accept this argument. It's just that my feeling is that we are > lacking proper review of the required call sites of cpu_sychronize_state > and rather put it where some regression popped up (and that only in > qemu-kvm...). > That's life... > The new rule is: Synchronize the states before accessing registers (or > in-kernel devices) the first time after a vmexit to user space. No, the rule is: synchronize state before accessing registers. Extra synchronization is cheap, while missing synchronization is very expensive. > But, > e.g., I do not see where we do this on CPU reset. > That's a bug.
On Thu, Sep 24, 2009 at 10:53:59AM +0300, Avi Kivity wrote: > On 09/23/2009 06:45 PM, Jan Kiszka wrote: > >>Functions calling each other in the same subsystem can rely on callers > >>calling cpu_synchronize_state(). Across subsystems, that's another > >>matter, exported functions should try not to rely on implementation > >>details of their callers. > >> > >>(You might argue that the apic is not separate subsystem wrt an x86 cpu, > >>and I'm not sure I have a counterargument) > >> > >I do accept this argument. It's just that my feeling is that we are > >lacking proper review of the required call sites of cpu_sychronize_state > >and rather put it where some regression popped up (and that only in > >qemu-kvm...). > > That's life... > > >The new rule is: Synchronize the states before accessing registers (or > >in-kernel devices) the first time after a vmexit to user space. > > No, the rule is: synchronize state before accessing registers. > Extra synchronization is cheap, while missing synchronization is > very expensive. > So should we stick cpu_synchronize_state() before each register accesses? I think it is reasonable to omit it if all callers do it already. > >But, > >e.g., I do not see where we do this on CPU reset. > > That's a bug. > Only if kvm support cpus without apic. Otherwise CPU is reset by apic_reset() and cpu_synchronize_state() is called there. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Gleb Natapov wrote: > On Thu, Sep 24, 2009 at 10:53:59AM +0300, Avi Kivity wrote: >> On 09/23/2009 06:45 PM, Jan Kiszka wrote: >>>> Functions calling each other in the same subsystem can rely on callers >>>> calling cpu_synchronize_state(). Across subsystems, that's another >>>> matter, exported functions should try not to rely on implementation >>>> details of their callers. >>>> >>>> (You might argue that the apic is not separate subsystem wrt an x86 cpu, >>>> and I'm not sure I have a counterargument) >>>> >>> I do accept this argument. It's just that my feeling is that we are >>> lacking proper review of the required call sites of cpu_sychronize_state >>> and rather put it where some regression popped up (and that only in >>> qemu-kvm...). >> That's life... >> >>> The new rule is: Synchronize the states before accessing registers (or >>> in-kernel devices) the first time after a vmexit to user space. >> No, the rule is: synchronize state before accessing registers. >> Extra synchronization is cheap, while missing synchronization is >> very expensive. >> > So should we stick cpu_synchronize_state() before each register > accesses? I think it is reasonable to omit it if all callers do it > already. > >>> But, >>> e.g., I do not see where we do this on CPU reset. >> That's a bug. >> > Only if kvm support cpus without apic. Otherwise CPU is reset by > apic_reset() and cpu_synchronize_state() is called there. No, that's not enough if cpu_reset() first fiddles with some registers that may later on be overwritten on cpu_synchronize_state() with the old in-kernel state. At least in theory, haven't checked yet what happens in reality. That's why not synchronizing properly is "expensive" (or broken IOW). Jan
On 09/24/2009 11:03 AM, Gleb Natapov wrote: >> >>> The new rule is: Synchronize the states before accessing registers (or >>> in-kernel devices) the first time after a vmexit to user space. >>> >> No, the rule is: synchronize state before accessing registers. >> Extra synchronization is cheap, while missing synchronization is >> very expensive. >> >> > So should we stick cpu_synchronize_state() before each register > accesses? I think it is reasonable to omit it if all callers do it > already. > If the callee is static we can and should avoid it. If the function is exported then we shouldn't rely on callers. IOW, it's fine to depend on local details (which a reader can easily gain), but better to avoid depending on global details.
On Thu, Sep 24, 2009 at 10:15:15AM +0200, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Thu, Sep 24, 2009 at 10:53:59AM +0300, Avi Kivity wrote: > >> On 09/23/2009 06:45 PM, Jan Kiszka wrote: > >>>> Functions calling each other in the same subsystem can rely on callers > >>>> calling cpu_synchronize_state(). Across subsystems, that's another > >>>> matter, exported functions should try not to rely on implementation > >>>> details of their callers. > >>>> > >>>> (You might argue that the apic is not separate subsystem wrt an x86 cpu, > >>>> and I'm not sure I have a counterargument) > >>>> > >>> I do accept this argument. It's just that my feeling is that we are > >>> lacking proper review of the required call sites of cpu_sychronize_state > >>> and rather put it where some regression popped up (and that only in > >>> qemu-kvm...). > >> That's life... > >> > >>> The new rule is: Synchronize the states before accessing registers (or > >>> in-kernel devices) the first time after a vmexit to user space. > >> No, the rule is: synchronize state before accessing registers. > >> Extra synchronization is cheap, while missing synchronization is > >> very expensive. > >> > > So should we stick cpu_synchronize_state() before each register > > accesses? I think it is reasonable to omit it if all callers do it > > already. > > > >>> But, > >>> e.g., I do not see where we do this on CPU reset. > >> That's a bug. > >> > > Only if kvm support cpus without apic. Otherwise CPU is reset by > > apic_reset() and cpu_synchronize_state() is called there. > > No, that's not enough if cpu_reset() first fiddles with some registers > that may later on be overwritten on cpu_synchronize_state() with the old > in-kernel state. At least in theory, haven't checked yet what happens in Can't happen. Call chain is apic_reset() -> cpu_reset() and apic_reset() calls cpu_synchronize_state() before calling cpu_reset(). > reality. That's why not synchronizing properly is "expensive" (or broken > IOW). > > Jan > -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Gleb Natapov wrote: > On Thu, Sep 24, 2009 at 10:15:15AM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Thu, Sep 24, 2009 at 10:53:59AM +0300, Avi Kivity wrote: >>>> On 09/23/2009 06:45 PM, Jan Kiszka wrote: >>>>>> Functions calling each other in the same subsystem can rely on callers >>>>>> calling cpu_synchronize_state(). Across subsystems, that's another >>>>>> matter, exported functions should try not to rely on implementation >>>>>> details of their callers. >>>>>> >>>>>> (You might argue that the apic is not separate subsystem wrt an x86 cpu, >>>>>> and I'm not sure I have a counterargument) >>>>>> >>>>> I do accept this argument. It's just that my feeling is that we are >>>>> lacking proper review of the required call sites of cpu_sychronize_state >>>>> and rather put it where some regression popped up (and that only in >>>>> qemu-kvm...). >>>> That's life... >>>> >>>>> The new rule is: Synchronize the states before accessing registers (or >>>>> in-kernel devices) the first time after a vmexit to user space. >>>> No, the rule is: synchronize state before accessing registers. >>>> Extra synchronization is cheap, while missing synchronization is >>>> very expensive. >>>> >>> So should we stick cpu_synchronize_state() before each register >>> accesses? I think it is reasonable to omit it if all callers do it >>> already. >>> >>>>> But, >>>>> e.g., I do not see where we do this on CPU reset. >>>> That's a bug. >>>> >>> Only if kvm support cpus without apic. Otherwise CPU is reset by >>> apic_reset() and cpu_synchronize_state() is called there. >> No, that's not enough if cpu_reset() first fiddles with some registers >> that may later on be overwritten on cpu_synchronize_state() with the old >> in-kernel state. At least in theory, haven't checked yet what happens in > Can't happen. Call chain is apic_reset() -> cpu_reset() and apic_reset() > calls cpu_synchronize_state() before calling cpu_reset(). And system_reset? Jan
On Thu, Sep 24, 2009 at 10:59:46AM +0200, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Thu, Sep 24, 2009 at 10:15:15AM +0200, Jan Kiszka wrote: > >> Gleb Natapov wrote: > >>> On Thu, Sep 24, 2009 at 10:53:59AM +0300, Avi Kivity wrote: > >>>> On 09/23/2009 06:45 PM, Jan Kiszka wrote: > >>>>>> Functions calling each other in the same subsystem can rely on callers > >>>>>> calling cpu_synchronize_state(). Across subsystems, that's another > >>>>>> matter, exported functions should try not to rely on implementation > >>>>>> details of their callers. > >>>>>> > >>>>>> (You might argue that the apic is not separate subsystem wrt an x86 cpu, > >>>>>> and I'm not sure I have a counterargument) > >>>>>> > >>>>> I do accept this argument. It's just that my feeling is that we are > >>>>> lacking proper review of the required call sites of cpu_sychronize_state > >>>>> and rather put it where some regression popped up (and that only in > >>>>> qemu-kvm...). > >>>> That's life... > >>>> > >>>>> The new rule is: Synchronize the states before accessing registers (or > >>>>> in-kernel devices) the first time after a vmexit to user space. > >>>> No, the rule is: synchronize state before accessing registers. > >>>> Extra synchronization is cheap, while missing synchronization is > >>>> very expensive. > >>>> > >>> So should we stick cpu_synchronize_state() before each register > >>> accesses? I think it is reasonable to omit it if all callers do it > >>> already. > >>> > >>>>> But, > >>>>> e.g., I do not see where we do this on CPU reset. > >>>> That's a bug. > >>>> > >>> Only if kvm support cpus without apic. Otherwise CPU is reset by > >>> apic_reset() and cpu_synchronize_state() is called there. > >> No, that's not enough if cpu_reset() first fiddles with some registers > >> that may later on be overwritten on cpu_synchronize_state() with the old > >> in-kernel state. At least in theory, haven't checked yet what happens in > > Can't happen. Call chain is apic_reset() -> cpu_reset() and apic_reset() > > calls cpu_synchronize_state() before calling cpu_reset(). > > And system_reset? > And system_reset calls apic_reset() if cpu has apic, cpu_reset() otherwise. That is why I said that the bug is only for cpus without apic. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Gleb Natapov wrote: > On Thu, Sep 24, 2009 at 10:59:46AM +0200, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> On Thu, Sep 24, 2009 at 10:15:15AM +0200, Jan Kiszka wrote: >>>> Gleb Natapov wrote: >>>>> On Thu, Sep 24, 2009 at 10:53:59AM +0300, Avi Kivity wrote: >>>>>> On 09/23/2009 06:45 PM, Jan Kiszka wrote: >>>>>>>> Functions calling each other in the same subsystem can rely on callers >>>>>>>> calling cpu_synchronize_state(). Across subsystems, that's another >>>>>>>> matter, exported functions should try not to rely on implementation >>>>>>>> details of their callers. >>>>>>>> >>>>>>>> (You might argue that the apic is not separate subsystem wrt an x86 cpu, >>>>>>>> and I'm not sure I have a counterargument) >>>>>>>> >>>>>>> I do accept this argument. It's just that my feeling is that we are >>>>>>> lacking proper review of the required call sites of cpu_sychronize_state >>>>>>> and rather put it where some regression popped up (and that only in >>>>>>> qemu-kvm...). >>>>>> That's life... >>>>>> >>>>>>> The new rule is: Synchronize the states before accessing registers (or >>>>>>> in-kernel devices) the first time after a vmexit to user space. >>>>>> No, the rule is: synchronize state before accessing registers. >>>>>> Extra synchronization is cheap, while missing synchronization is >>>>>> very expensive. >>>>>> >>>>> So should we stick cpu_synchronize_state() before each register >>>>> accesses? I think it is reasonable to omit it if all callers do it >>>>> already. >>>>> >>>>>>> But, >>>>>>> e.g., I do not see where we do this on CPU reset. >>>>>> That's a bug. >>>>>> >>>>> Only if kvm support cpus without apic. Otherwise CPU is reset by >>>>> apic_reset() and cpu_synchronize_state() is called there. >>>> No, that's not enough if cpu_reset() first fiddles with some registers >>>> that may later on be overwritten on cpu_synchronize_state() with the old >>>> in-kernel state. At least in theory, haven't checked yet what happens in >>> Can't happen. Call chain is apic_reset() -> cpu_reset() and apic_reset() >>> calls cpu_synchronize_state() before calling cpu_reset(). >> And system_reset? >> > And system_reset calls apic_reset() if cpu has apic, cpu_reset() > otherwise. That is why I said that the bug is only for cpus without > apic. Yes, I see now. Still, it's not a good reference for other archs (did anyone already checked the situation on ppc?). Will file a patch. Jan
diff --git a/hw/apic.c b/hw/apic.c index 3a2e128..a9d1fb8 100644 --- a/hw/apic.c +++ b/hw/apic.c @@ -488,7 +488,6 @@ void apic_init_reset(CPUState *env) if (!s) return; - cpu_synchronize_state(env); s->tpr = 0; s->spurious_vec = 0xff; s->log_dest = 0;
Each caller of the function already calls it. Signed-off-by: Gleb Natapov <gleb@redhat.com> --- hw/apic.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)