Lines Matching refs:t

60 The KVM x86 tree doesn't have its own official merge window, but there's a soft
74 i.e. radio silence during this period isn't unusual.
116 variable declarations isn't strictly required, though it is still preferred.
119 functions.  The vast majority of "public" KVM functions aren't truly public as
140 and APM are constantly changing, and so the numbers/labels aren't stable.
166 Note, these don't align with the topics branches (the topic branches care much
185 you want to propose introducing a new topic, i.e. don't go rogue.
220 short then the order doesn't matter.  But if one is shorter (almost always the
228 If a change fixes a KVM/kernel bug, add a Fixes: tag even if the change doesn't
233 "Cc: stable@vger.kernel" (though the email itself doesn't need to Cc: stable);
247 isn't feasible, but the more the merrier.  KVM_SMM, KVM_XEN, PROVE_LOCKING, and
269 If you can't fully test a change, e.g. due to lack of hardware, clearly state
275 tests aren't strictly required, e.g. if coverage is provided by running a
283 can't prevent a guest from using and for which there is no true enabling.
286 that can't be well validated using existing KVM selftests and/or KVM-unit-tests
320 is useless for anyone that doesn't have the original message, e.g. if someone
321 wasn't Cc'd on the bug report or if the list of recipients changes between
354 KVM-unit-tests should *always* be posted separately.  Tools, e.g. b4 am, don't