Date: Thu, 30 Apr 2015 16:40:13 +0200 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com> To: =?windows-1252?Q?Gustau_P=E9rez?= <gperez@entel.upc.edu>, FreeBSD XEN <freebsd-xen@freebsd.org> Subject: Re: Porting the block-iscsi hotplug script Message-ID: <55423ECD.6000404@citrix.com> In-Reply-To: <5542365D.10403@entel.upc.edu> References: <553DEB97.5000300@entel.upc.edu> <5540A053.4080409@entel.upc.edu> <5540F3FC.80606@citrix.com> <5541FC8A.8080009@citrix.com> <5542365D.10403@entel.upc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, El 30/04/15 a les 16.04, Gustau Pérez ha escrit: > > > El 30/04/2015 a les 11:57, Roger Pau Monné ha escrit: >> I've been digging into this, and it looks like it's going to be more >> complicated than what I thought. FreeBSD blkback is not prepared to work >> with hotplug scripts so we also need to modify it. >> >> I hope I'm going to have some time next week to prepare a patch to both >> the FreeBSD kernel and libxl, sorry for the delay. > > Hi Roger and thanks for your time and efforts. > > I thought XENBUS_PATH was some sort of a reference to the xenstore > path of the VM being executed and that the libxl would export that to > the hotplug scripts. I thought that simply allowing the libxl to execute > hotplug script for blk devices would be enough. > > Can I be of any help? Feel free to pass me work I you're busy. > > OTOH, I wasn't aware it could involve the Dom0 kernel. I'm confused > about that, could you please explain me why it does involve the dom0 > kernel? Sure, in order to provide paravirtualized network and disks to the guests Xen uses what is called a split device model. In the block case, this is done by having a specific driver in the guest kernel, called blkfront, and another driver in the host kernel (Dom0) called blkback. When the guest starts a region of the guest memory is mapped by blkback in order to have a transparent exchange of data between the host and the guest, and that's how disk PV drivers are implemented. blkback runs inside of the FreeBSD kernel and in order to know which file or block device is the backend of a guest virtual disk it reads a node in xenstore, which is called "params". This is directly written by libxl and is the path to the block or raw file in the common case (but when using iSCSI it just contains the information needed to connect to the target, which blkback doesn't understand at all). On Linux for example blkback doesn't read "params" directly, and instead uses another node that's written by the hotplug script upon execution, so blkback attachment is deferred until hotplug script execution has finished. We need something like this in FreeBSD blkback, in order to have the following workflow: 1. libxl populates xenstore nodes. 2. hotplug script execution. 3. blkback attaches the disk. With the current blkback code there's no way to guarantee that 3 happens after 2. > Thank you, > > Gus > > PS: a bit offtopic, but I've been reviewing the commits to FreeBSD > HEAD and I don't see this: > > https://people.freebsd.org/~royger/mem.patch > > IIRC that patch solved the problem of domU PV guests with some > hardware. Could you commit that upstream? Yes, I was waiting to see if Justin had any comments on it. If nothing comes up next week I will just commit it. Roger.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55423ECD.6000404>