Make sure guest spans are setup as late as possible to avoid human error

with #924 merging, guest span is setup before calling run_vcpu. In the future, if any spans are created in run_vcpu method, then the spans will be malformed. We should change the api to make sure this cannot happen

Before #924, the guest span was set up immediately before entering the guest

hyperlight/src/hyperlight_host/src/hypervisor/kvm.rs

Lines 602 to 604 in 817a7b0

    
           tc.setup_guest_trace(Span::current().context()); 
        
           let exit_reason = self.vcpu_fd.run();

After #924, the span is setup in a different functions compared to where we enter the guest (note that run_vcpu does not immediately enter the guest, depending on which hv driver we use):

hyperlight/src/hyperlight_host/src/hypervisor/hyperlight_vm.rs

Lines 385 to 390 in 70a2c15

    
           tc.setup_guest_trace(Span::current().context()); 
        
           // ==== KILL() TIMING POINT 3: Before calling run() ==== 
        
           // If kill() is called and ran to completion BEFORE this line executes: 
        
           //    - Will still do a VM entry, but signals will be sent until VM exits 
        
           let result = self.vm.run_vcpu();

and in mshv (also see kvm and whp)

hyperlight/src/hyperlight_host/src/hypervisor/virtual_machine/mshv.rs

Lines 106 to 115 in 70a2c15

    
           fn run_vcpu(&mut self) -> Result<VmExit> { 
        
               const HALT_MESSAGE: hv_message_type = hv_message_type_HVMSG_X64_HALT; 
        
               const IO_PORT_INTERCEPT_MESSAGE: hv_message_type = 
        
                   hv_message_type_HVMSG_X64_IO_PORT_INTERCEPT; 
        
               const UNMAPPED_GPA_MESSAGE: hv_message_type = hv_message_type_HVMSG_UNMAPPED_GPA; 
        
               const INVALID_GPA_ACCESS_MESSAGE: hv_message_type = hv_message_type_HVMSG_GPA_INTERCEPT; 
        
               #[cfg(gdb)] 
        
               const EXCEPTION_INTERCEPT: hv_message_type = hv_message_type_HVMSG_X64_EXCEPTION_INTERCEPT; 
        
               let exit_reason = self.vcpu_fd.run();

This means that if a developer in the future changes code so that it emits an event in between these two places (because they forgot you're not supposed to), for example at the top of run_vcpu, the event emitted on the host side will be inside the guest span (incorrect!). The fix should be to move these two places right next to each other so that it's impossible for us (developers) to forget about this in the future. Probably by passing in the tracing context to run_vcpu, and then calling setup_guest_trace right before run_vcpu

Closes hyperlight-dev#1076: Code refactor to set trace context in run…

Navigation Menu

Repository navigation

Make sure guest spans are setup as late as possible to avoid human error #1076

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	tc.setup_guest_trace(Span::current().context());

	let exit_reason = self.vcpu_fd.run();

	tc.setup_guest_trace(Span::current().context());

	// ==== KILL() TIMING POINT 3: Before calling run() ====
	// If kill() is called and ran to completion BEFORE this line executes:
	// - Will still do a VM entry, but signals will be sent until VM exits
	let result = self.vm.run_vcpu();

	fn run_vcpu(&mut self) -> Result<VmExit> {
	const HALT_MESSAGE: hv_message_type = hv_message_type_HVMSG_X64_HALT;
	const IO_PORT_INTERCEPT_MESSAGE: hv_message_type =
	hv_message_type_HVMSG_X64_IO_PORT_INTERCEPT;
	const UNMAPPED_GPA_MESSAGE: hv_message_type = hv_message_type_HVMSG_UNMAPPED_GPA;
	const INVALID_GPA_ACCESS_MESSAGE: hv_message_type = hv_message_type_HVMSG_GPA_INTERCEPT;
	#[cfg(gdb)]
	const EXCEPTION_INTERCEPT: hv_message_type = hv_message_type_HVMSG_X64_EXCEPTION_INTERCEPT;

	let exit_reason = self.vcpu_fd.run();

Make sure guest spans are setup as late as possible to avoid human error #1076

Description

Activity

ludfjig commented on Jan 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions