On 10/8/25 04:52, Naveen N Rao wrote:
> On Tue, Oct 07, 2025 at 08:31:47AM -0500, Tom Lendacky wrote:
>> On 9/25/25 05:17, Naveen N Rao (AMD) wrote:
>
> ...
>
>>> +
>>> +static void
>>> +sev_snp_guest_set_tsc_frequency(Object *obj, Visitor *v, const char *name,
>>> + void *opaque, Error **errp)
>>> +{
>>> + uint32_t value;
>>> +
>>> + if (!visit_type_uint32(v, name, &value, errp)) {
>>> + return;
>>> + }
>>> +
>>> + SEV_SNP_GUEST(obj)->tsc_khz = value / 1000;
>>
>> This will cause a value that isn't evenly divisible by 1000 to be
>> rounded down, e.g.: tsc-frequency=2500000999. Should this name instead
>> just be tsc-khz or secure-tsc-khz (to show it is truly associated with
>> Secure TSC)?
>
> I modeled this after the existing tsc-frequency parameter on the cpu
> object to keep it simple (parameter is the same, just where it is
> specified differs). This also aligns with TDX which re-uses the
> tsc-frequency parameter on the cpu object.
So why aren't we using the one on the cpu object instead of creating a
duplicate parameter? There should be some way to get that value, no?
Thanks,
Tom
>
>>
>> Also, I think there is already a "tsc-freq" parameter for the -cpu
>> parameter (?), should there be some kind of error message if both of
>> these are set? Or a warning saying it is being ignored? Or ...?
>
> This is validated when the TSC frequency is being set on the vcpu, so I didn't
> add an explicit check.
>
> As an example, with:
> -cpu EPYC-v4,tsc-frequency=2500000000 \
> -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1,secure-tsc=on
>
> qemu-system-x86_64: warning: TSC frequency mismatch between VM (2500000 kHz)
> and host (2596099 kHz), and TSC scaling unavailable
> qemu-system-x86_64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid
> argument
>
>
> Thanks,
> Naveen
>
