On Mon, 26 Nov 2018 at 17:18, gengdongjiu <gengdongjiu@xxxxxxxxxx> wrote: > > Hi Peter, > Thanks for the comments. > > > > > Yes, but if you look at the code which calls that, it goes on to do: > > env->mcg_cap &= mcg_cap | MCG_CAP_BANKS_MASK; > > > > which means that if the host kernel does not support this feature then we will clear those bits in the env->mcg_cap field, so we do not > > advertise it to the guest. But we might be not advertising it to the guest at all, if env->mcg_cap was 0 before this code was called. That > > happens if we are presenting the guest with a guest CPU type which does not have the feature. > > So you mean "env->mcg_cap" uses a bit to indicate that whether guest CPU support error recovery, right? If so, how we know whether guest CPU have this feature? > Should we initialized MCG_SER_P bit of env->mcg_cap to 1 or 0 before initializing the vcpu? Please together see the reply in the [2], thanks. This is an x86-specific field. We need to identify the Arm equivalent. > > The question is not "does the host CPU / KVM support error reporting". It is "does the *guest* CPU / system support error reporting". > > These are distinct questions which may not have the same answer. > > [2]: > But QEMU should not know whether *guest* CPU / system support error reporting. It should and it must. Otherwise we will deliver an exception to a guest that cannot handle it. > From my understanding, in the X86 platform, if host CPU / KVM support error reporting, > then it will think guest CPU supports error reporting, and set the > MCG_SER_P bit of env->mcg_cap to 1 No, this is not correct. If you look at the code quoted above. it ANDs in the mcg_cap value. This code is run after the CPU is initially created with a default env->mcg_cap which depends on what CPU model is being exposed to the guest. So we only set env->mcg_cap to 1 if the guest vCPU model supports error reporting AND the host KVM does. thanks -- PMM
