On 24.09.2025 12:13, Grygorii Strashko wrote: > On 19.09.25 23:49, Jan Beulich wrote: >> On 19.09.2025 18:31, Grygorii Strashko wrote: >>> @@ -1136,6 +1136,9 @@ static int cf_check viridian_load_domain_ctxt( >>> struct viridian_domain *vd = d->arch.hvm.viridian; >>> struct hvm_viridian_domain_context ctxt; >>> >>> + if ( !is_viridian_domain(d) ) >>> + return 0; >>> + >>> if ( hvm_load_entry_zeroextend(VIRIDIAN_DOMAIN, h, &ctxt) != 0 ) >>> return -EINVAL; >>> >>> @@ -1172,6 +1175,9 @@ static int cf_check viridian_load_vcpu_ctxt( >>> struct vcpu *v; >>> struct hvm_viridian_vcpu_context ctxt; >>> >>> + if ( !is_viridian_domain(d) ) >>> + return 0; >> >> I don't think we should let these go through, but rather flag an error. >> And perhaps an intentionally exotic one (e.g. EILSEQ or something yet >> more "odd"). > > Most of existing load_x() returns -ENODEV (for example pit_load() for > !has_vpit()). > Some -EOPNOTSUPP. > > I'd be very much appreciated if you could explicitly specify err code to be > used. > -EILSEQ? or -ENODEV? or ..
Well, I did already suggest EILSEQ, didn't I? I merely wanted to leave open for you to pick "something yet more odd". Jan
