- Aug 14, 2013
-
-
Avi Kivity authored
Needed for libstdc++ from gcc 4.8.1
-
Avi Kivity authored
-
- Aug 13, 2013
-
-
Avi Kivity authored
It doesn't exist there. [ glommer: use the alternative system ]
-
Glauber Costa authored
To make matters even clearer, enclose the main alternative macro in a xen-specific macro, so we don't have to code xen's presence condition everywhere.
-
Glauber Costa authored
I am proposing, with this patch, a very simple alternative system to serve as a basis for xen pv operations. The end goal is to patch the performance critical instructions in, but I will defer it until later since this is a performance optmization. Let's get that working first. However, I figured that if we are already writing the xen pv code enclosed in some kind of macro, then when we do patch, we won't have to change anything. That said, I don't expect to have a lot of pure pv users - It is 2013, and even VMWare discontinued their vmi, leaving Xen as the only relevant player. We don't need, then, a fully featured core-pv ops like Linux. This system of alternatives is simple enough to accomodate xen, and it works by providing two code blocks and a condition. The first block is executed if the condition is false, and the second if the condition is true. For future reference, note that we can use when patching by doing something very similar to Linux jump labels: we replace the branch with a jump instruction that just jumps to the right place (taken or not-taken part). This brings simplicity and runtime efficiency at the expense of a little bit more icache pressure.
-
Avi Kivity authored
Add a xen_init() function (currently only stores the start_info pointer) and jump to the normal init sequence. [ glommer: rebased to current tip ]
-
Avi Kivity authored
This metadata identifies the kernel to Xen and enables the pv loader. [ glommer: adjusted to current tip and fixed header include ]
-
Glauber Costa authored
Now that we have everything in place, ask the loader to be able to probe the xenbus.
-
Glauber Costa authored
The xen block driver needs some extra state not needed for the network drivers. Namely, the same way virtio-blk does, we need to tell the block layer which is our strategy, read and write functions. For that, we need some extra code that I am implementing in xenfront-blk.cc.
-
Glauber Costa authored
BSD expects its sector number to be already provided by the bio. We could add this field to the bio, but it is easier just to calculate it from the given offset. There are many places in which the bios are filled up, including many in the zfs code. So it is easier to change them just here.
-
Glauber Costa authored
Simple implementation of BSD's bus_dma interface. Since we are constrained by virtual environments, we are able to cut out most of the things.
-
Glauber Costa authored
We will use it in our bus_dma implementation
-
Glauber Costa authored
Our version of biodone takes two arguments instead of one. Adjust it, passing the status in the second argument as expected. We could adjust our biodone() function to be the same as BSD's, but I decided to do the other way around, at least for now: we need locking and synchronization via cond vars at bio completion, and although the xenfront driver has its own lock for this, the other users rely on the internal lock for correctness. Adjusting them would mean adjusting their locking semantics, which although doable, is just more work than adjusting xenfront.
-
Glauber Costa authored
We need to add our headers first, but the rest should be ready to go.
-
Glauber Costa authored
It provides very simple queue / dequeue functions for the bios.
-
Glauber Costa authored
This is used by subr_disk during bio flush operation
-
Glauber Costa authored
-
Glauber Costa authored
With all the infrastructure in place, we can compile all our xenbus code in, and enble the netfront driver.
-
Glauber Costa authored
BSD code does not initialize its structures.. It works well when memory is previously zeroed but not otherwise. Xen hypervisor compiled in debug mode fills memory with a poison pattern, and then the code breaks for those variables. Force them to 0.
-
Glauber Costa authored
We need bsd/ directory listed in includes not only for bsd/ files, but for our cpp code as well. So it has to be in the main includes. Second, I was overly optmistic about the interface version. The drivers expect an inteface version slightly older than the maximum present in headers.
-
Glauber Costa authored
Those headers are needed from blkfront and netfront. Some of them are empty stubs are usual but some are import from BSD. I am bringing them separately so it is obvious what they are here for.
-
Glauber Costa authored
The macro to calculate ring size are really gigantic and nested. Somewhere, somehow, gcc believes that one of the size calculations yields a variadic size. It doesn't seem to be the case to me, but maybe we are using (or lacking) some compiler flag that can explain this. Although this is clearly suboptimal, let us set with this for now. It should not be a huge problem unless we update xen headers.
-
Glauber Costa authored
Because softc is private - only a void pointer outside blkfront, we need a helper here to return the correct device from its softc representation. This will be used by the osv side to determine where to trigger IO to
-
Glauber Costa authored
BSD uses non-standard device names (standard here meaning us) for the network and block interfaces. There is no reason for us to play the complexity to deal with different names, so change it.
-
Glauber Costa authored
This patch contains the trivial osv adjustments for osv, like type fixing, header conciliation, sysctl removal, etc.
-
Glauber Costa authored
We won't implement interface media change routines - at least for now, so stub them.
-
Glauber Costa authored
Those are: type conciliation, osv porting header inclusion and deleting unused statements.
-
Glauber Costa authored
There are many other bio fields and functions that blkfront uses that are not provided by our simplified bio. I am adding them here. One of the things we need is a type definition of daddr_t. This already exists in fatfs.h, but it makes more sense to live in the lower level code. So instead of including fatfs in bio.h, I am including bio.h in fatfs and moving the daddr_t definition here.
-
Glauber Costa authored
Current test does: (((ifq)->ifq_drv_len == 0) && ((ifq)->ifq_len == 0)) but ifq_drv_len does not exist. Funny enough, it does not exist in BSD basic interface queue as well.
-
Glauber Costa authored
Some block devices, such as the Xen blkfront, will have a maximum per-request size that needs to be obeyed. In order for us to do it, we'll need to be aware of this requirement in upper layers. So set up the device with it. We initialize the default structure to make sure only interested parties need to set this up.
-
Glauber Costa authored
For xen, I would like to use an already existing device instead of creating one. I still need to register it, though. I am here factoring out device_create in a allocation and a registering part so I can use the later by itself.
-
Glauber Costa authored
This commit includes the basic translation layer so we can support BSD devices for Xen as is. I believe there is room for improvement, but that provides a very good starting point. I would like to provide you guys with a smaller commit, but it is quite cumbersome to separate the device implementation from the bus implementation per se. Part of it is due to the way Xen does things. For instance: when we are talking virtio devices, each of them will have its own pci device. For xen, only one pci device will be exposed, with its own interrupt, and that will be the xenbus. The xenbus is then responsible for querying the xenstore and figuring out which devices are there. Maybe there is a different way of doing things (I believe for instance that there is no reason to have shared interrupts between all devices) but that is the way BSD does things. And about the bus-is-the-device, even Linux as far as I know. Another thing to note, is that BSD devices registered with a device_method_t seem to be fully hierarchical. I am not doing it this way here (I am mostly ignoring the xenbus device_method_t definitions), which means there are a lot of assumptions that probably won't hold with other kinds of drivers. But it should not be hard to extend, and that simplifies things.
-
Glauber Costa authored
By issuing this hypercall, we can control where xen delivers the interrupt to. Right now we will only support vectored callbacks. It should not be hard to extend this for gsi and intx for HVM guests.
-
Glauber Costa authored
If we have this array, BSD code that checks for features can run unmodified.
-
Glauber Costa authored
Changes needed for xenbus operation. They are, as usual: * delete function tables and make previously static functions on it public * comment out sysctl code * change order of includes between sbuf.h and malloc.h. sbuf calls into our functions, and those have a single malloc instead of a 3-argument one. This is by far the easiest way to handle this * Modify calling convention for device_add_child. It is just way easier if we now the path at creation time. BSD does not need it because it creates all devices equal (they are the same device_t structure), but for us is way more convenient if we can create the appropriate classes.
-
Glauber Costa authored
In particular, I am not implementing the struct filling in the end of the file. Just comment it out, and make the relevant static functions public. We will call them from our code.
-
Glauber Costa authored
As suggested by Guy
-
Glauber Costa authored
-
Glauber Costa authored
Mostly trivial changes needed to compile the pv event channel. We need some type adjustments, but the most complex ones are assembly fixes. Because BSD seems to only do this for 32-bit guests, we need to adjust the inline asm instructions to take quad words for longs, and force int types for double words. After this, the evtchn can be compiled.
-
Glauber Costa authored
This file implements the pv and pv-on-hvm event channel mechanism. Verbatim copy from BSD.
-