Re: Enhance perf to support KVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/26/2010 04:35 AM, Ingo Molnar wrote:
Basically what is needed is plain filesystem access - properly privileged. So
doing this via a vmchannel would be nice, but for the symbol extraction it
would be a glorified NFS server in essence.

Do you have (or plan) any turn-key 'access to all files of the guest' kind of
guest-transparent facility that could be used for such purposes? That would
have various advantages over a traditional explicit file server approach:

  - it would not contaminate the guest port space

  - no guest side configuration needed (the various oprofile remote daemons
    always sucked as they needed extra setup)

  - it might even be used with a guest that does no networking

If you look at VMware, they provide a guest daemon that runs in userspace and communicates with the host to allow the host to do operations like execute a binary or read a file.

We've been trying to build this for years and virtio-console is what we've finally settled on. The userspace bits are super easy to build. The problem is that we need guest kernel support. We've not had a lot of success there as we've had a number of things Nacked. The approach we originally started with was to introduce a new socket family for virtualization. This is what s390 does and this is what VMware does.

But Dave Miller nacked that. VMware happily carries their own module so they don't have to deal with problems like this. I guess s390 was able to get away with it because noone pays attention to what they do.

Rusty had a proposal very similar to vhost-net that he posted two years ago but Andrew Morton nacked that because it wasn't generic enough (serves us right for trying to do anything generic in the first place).

Honestly, what's hardest for us to build a turn key solution is that unlike our competition, we've got to deal with getting people who don't necessarily care about virtualization to agree with what we're doing as opposed to just maintaining our own set of kernel modules.

Things limited to userspace have not slowed us down compared to getting things into the kernel. Look at how difficult it was to get MMU notifiers merged as another example.

If you're volunteering to commit the things that we need to build a turn key solution, then that would certainly be a big help to us.

Regards,

Anthony Liguori

--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux