Xen is not a full hypervisor until it loads the first domain - dom0, which is (except for Sun's Xen) a Linux kernel + userspace. (Hence the patchset). Without dom0 Xen does not have any device support (other than cpu/mmu/ioapic), management or control interfaces, or accessibility (terminal or vnc server). So it is not correct to say Xen is different from KVM in the sense that only KVM requires a Linux host: so does Xen. Again, you don't have a Xen hypervisor without a dom0 Linux. So really, the Xen hypervisor is not any more lightweight than KVM, and you can't run it standalone (not if you want it to run any guests). When making this calculus, Xen + dom0 is significantly more kloc than KVM + toolchain.
When evaluating Xen for security, you must audit the dom0 kernel + userspace right along with the Xen kernel. dom0 is a fully privileged guest - it has access to memory for all other guests. You end up with more kloc to evaulate with Xen than with KVM.
KVM also supports PCI device pass-through (the feature which allows each device to be driven by a separate domain. KVM runs paravirtual Linux kernels using the standard paravirt-ops interface.
Xen's approach to managing guest page tables (paravirtualization and batching of page table updates) will lose its benefit quickly as EPT (nested page table) support moves guest page table management into the processor. Nehalem and Barcelona both support this feature, which in some tests eliminates more than 90% of traps into the hypervisor.