On 10/25/18 4:10 PM, Alexandru Stefan ISAILA wrote: > On 25.10.2018 14:55, Jan Beulich wrote: >>>>> On 18.10.18 at 11:02, <[email protected]> wrote: >>> +struct x86_selector_reg { >>> + union >>> + { >>> + uint64_t bytes; >>> + struct >>> + { >>> + uint32_t base; >>> + uint32_t limit : 20; >>> + uint32_t ar : 12; >>> + } fields; >>> + }; >>> +}; >> >> I don't understand why sel was moved out. Are you tight on >> space here, such that you can't tolerate the padding bytes? > > It was dropped on Andrew's suggestion. We are ok with it in the > structure so if is ok by you I can add it back.
We are tight on space. The ring buffer is only 4K, and it already can only fit about 10 sync vm_events before VCPUs need to be blocked waiting for a place in the buffer. That's why we've attempted the packing. >> Finally - what meaning to the low (or high) 4 bits of "ar" >> carry? > > If I correctly understand the question, we use ar bits to determine the > running mode of the guest. That's what we need the CS .ar for: looking at CS_AR_BYTES_D and CS_AR_BYTES_L, the rest we pass along to the introspection engine - I'd have to check with them for more details if requested. But I think we've probably misunderstood the question. Thanks, Razvan _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
