- Aug 13, 2013
-
-
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.
-
Glauber Costa authored
The BSD pv event channel will expect the underlying OS to be able to register a PIC. For now we will just allow that for xen, and provide the expected translation functions to allow xen to work. The design I have chosen is to let the xen event handler run in interrupt context. We can do threaded if it really becomes a problem, but right now it should do. The handlers themselves, though, will be threaded. So the intr_execute_handlers() function will do nothing more than to wake the respective threads. BSD will provide us functions, not threads. So we have a common thread that executes the function that we were given. One exception for this is the xenstore. The xenstore is already threaded, and its interrupt handler will also just wake up a thread. So for that we could do better in the future.
-
Glauber Costa authored
This contains interrupts, devices and bus definitions. Most of them are is bus files in BSD anyway.
-
Glauber Costa authored
With this patch, the grant table code is compiled into osv. The edits in the file reflect the fact that we don't need to go through PCI memory for the Xen special device even for HVM. We have mappings that are way simpler, so we can just use them. All the rest is kept as unchanged as I could.
-
Glauber Costa authored
-
Glauber Costa authored
Xen files in BSD (and Linux for that matter) expect a variable called HYPERVISOR_shared_info that points to the hypercall page - that in our case is statically defined. So we just need to point it with the correct name to our shared info page. Note the type mismatch: we are defining our own xen_shared_info to be able to access some parts of the structure, like the wallclock, more conveniently. Because of that, we need a type cast.
-
Glauber Costa authored
Xen does not need to EOI. At least not with the APIC anywyay: it signals end of interrupt by flipping vcpu_info->evtchn_upcall_pending to 0, but that is already done by the BSD handler, so we might as well do nothing. Avi generalized the irq handler to have a pre_eoi and a handler, and in this patch I am taking the extra step of adding an EOI indirection as well.
-
Glauber Costa authored
This is for the lack of a better place.
-
Glauber Costa authored
-
Glauber Costa authored
-
Avi Kivity authored
Already specified elsewhere. Noted by Nadav.
-
Avi Kivity authored
The release build optimizes away references to this object, but the debug build does not. Define it.
-