Avi Kivity wrote: > Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> Jan Kiszka wrote: >>> >>>> Huh, it is! Then the problem is a KVM-only thing: The kernel part hooks >>>> onto those resources but doesn't communicate changes to this user space >>>> backend. >>>> >>> In this case, the -no-kvm-pit option should help. >>> >> >> Probably fine in many cases (where the PIT is no longer used anyway), >> just a bit unintuitive for users. >> > > Yes, it's only a workaround. > >> I wonder why KVM moved port 0x61 handling into kernel space at all. By >> leaving it in pcspk hands and extending the latter to sync with the >> in-kernel PIT on sample generation, this speaker regression (of >> kvm-userspace) should have been avoidable. >> > > I'd rather not have partial components in the kernel. This case is > particularly icky though. But you surely don't want to issue the sound from kernel space. Moreover, these are separate components: the PIT doesn't bother about the speaker, if it's on or off. We just need to make pcspk KVM-aware. I think I will post a patch later today. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
