On 02/05/2012 12:58 PM, Gleb Natapov wrote: > > > > > > > Reduced performance is what I mean. Obviously old guests will continue > > > working. > > > > I'm not happy about it either. > > > It is not only about old guests either. In RHEL we pretend to not > support HPET because when some guests detect it they are accessing > its mmio frequently for certain workloads. For Linux guests we can > avoid that by using kvmclock. For Windows guests I hope we will have > enlightenment timers + RTC, but what about other guests? *BSD? How often > they access HPET when it is available? We will probably have to move > HPET into the kernel if we want to make it usable.
If we have to, we'll do it. > So what is the criteria for device to be emulated in userspace vs kernelspace > in new API? Never? What about vhost-net then? Only if a device works in MSI > mode? This may work for HPET case, but looks like artificial limitation > since the problem with HPET is not interrupt latency, but mmio space > access. The criteria is, if it's absolutely necessary. > And BTW, what about enlightenment timers for Windows? Are we going to > implement them in userspace or kernel? The kernel. -- error compiling committee.c: too many arguments to function
