Hi, Had two more questions about scheduling mechanisms employed by Xen. Can you please answer them? 1. Say, DomU1 started transmitting packets over the network and got blocked. Dom0 is supposed to do the actual transmission and it did that. Eventually, when the reply came from the other side, nither Dom0 nor DomU1 is scheduled. How does hypervisor react to this interrupt? I can think of the following situations and you may be able to tell me which is correct: a. hypervisor preempts the currently running entity (which is neither DomU1/Dom0) and schedules Dom0 to complete the I/O. When Dom0 is done, the preempted guy is scheduled again. b. hypervisor preempts the currently running entity (which is neither DomU1/Dom0) and schedules Dom0 to complete the I/O. When Dom0 is done, DomU1 is scheduled. c. hypervisor does not do any preemption; schedules Dom0/DomU1 according to the predefined order. I don''t know if (c) is actually possible or not. If anything else happens in reality, please let me know. 2. Unmodified guest OSs can run on VT-x machine. What happens to the I/O activity done by each guest OS? Do they still rely on Dom0 or they perform I/O by themselves? Thanks, Amitayu _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Amitayu, Lets not cross-post. xen-devel is for development issues regarding Xen, xen-users is for users of Xen. Pertinent threads may migrate from one list to another. Further, a lot of Xen devs lurk around on the user list anyways. Now, onto your questions. On 2/28/06, Amitayu Das <amitayudas@gmail.com> wrote:> 1. Say, DomU1 started transmitting packets over the network and got > blocked. Dom0 is supposed to do the actual transmission and it did > that. Eventually, when the reply came from the other side, nither > Dom0 nor DomU1 is scheduled. How does hypervisor react to this > interrupt? I can think of the following situations and you may be > able to tell me which is correct: > a. hypervisor preempts the currently running entity (which is > neither DomU1/Dom0) and schedules Dom0 to complete the I/O. When > Dom0 is done, > the preempted guy is scheduled again. > > b. hypervisor preempts the currently running entity (which is > neither > DomU1/Dom0) and schedules Dom0 to complete the I/O. When Dom0 is > done, > DomU1 is scheduled. > > c. hypervisor does not do any preemption; schedules Dom0/DomU1 > according to the predefined order.IIUC (and I might be wrong), its neither of the above 3. When a packet comes in, Xen takes the interrupts and figures out which domain is to handle the interrupt (in this case, Dom0). *Whenever* Dom0 is scheduled next, it takes this interrupt and posts a virtual interrupt to the destination domain (Dom1). Again, *whenever* Dom1 is scheduled next, it deals with the packet. Depending on what you meant by "predefined" order, this might actually look like (c), except that Xen does preempt the originally running VM to take the interrupt. It then calls into the scheduler to figure out which domain to run next, just as it would normally. Hope that helps, Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Petersson, Mats
2006-Mar-01 10:36 UTC
RE: [Xen-users] Scheduling questions for I/O activity
> -----Original Message----- > From: xen-users-bounces@lists.xensource.com > [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of > Diwaker Gupta > Sent: 01 March 2006 01:14 > To: Amitayu Das > Cc: xen-users > Subject: Re: [Xen-users] Scheduling questions for I/O activity > > Amitayu, > > Lets not cross-post. xen-devel is for development issues > regarding Xen, xen-users is for users of Xen. Pertinent > threads may migrate from one list to another. Further, a lot > of Xen devs lurk around on the user list anyways. > > Now, onto your questions. > > On 2/28/06, Amitayu Das <amitayudas@gmail.com> wrote: > > 1. Say, DomU1 started transmitting packets over the > network and got > > blocked. Dom0 is supposed to do the actual transmission and it did > > that. Eventually, when the reply came from the other side, nither > > Dom0 nor DomU1 is scheduled. How does hypervisor react to this > > interrupt? I can think of the following situations and you may be > > able to tell me which is correct: > > a. hypervisor preempts the currently running entity (which is > > neither DomU1/Dom0) and schedules Dom0 to complete the I/O. > When Dom0 > > is done, the preempted guy is scheduled again. > > > > b. hypervisor preempts the currently running entity (which is > > neither > > DomU1/Dom0) and schedules Dom0 to complete the I/O. When Dom0 is > > done, > > DomU1 is scheduled. > > > > c. hypervisor does not do any preemption; schedules Dom0/DomU1 > > according to the predefined order. > > IIUC (and I might be wrong), its neither of the above 3. When > a packet comes in, Xen takes the interrupts and figures out > which domain is to handle the interrupt (in this case, Dom0). > > *Whenever* Dom0 is scheduled next, it takes this interrupt > and posts a virtual interrupt to the destination domain > (Dom1). Again, *whenever* > Dom1 is scheduled next, it deals with the packet. Depending > on what you meant by "predefined" order, this might actually > look like (c), except that Xen does preempt the originally > running VM to take the interrupt. It then calls into the > scheduler to figure out which domain to run next, just as it > would normally.Yup, the pseudo-code for interrupt handling is (much abbreviated) like this: void handle_interrupt() { set_event_for_owner(this_interrupt); schedule(); } Since the owner of most interrupts is Dom0, it most likely means that Dom0 is now able to run. The call to schedule will just schedule whatever is the "most important" domain. That''s entirely decided upon by the scheduler, and there''s even several different types of schedulers to choose from if you want to play around with that... You also asked about handling of interrupts in HVM (unmodified OS). This works pretty much the same way as the para-virtualized mode, except much of the hardware is simulated using a device-model (qemu-dm) that interprets accesses to hardware and "does the right thing". So for example, an access to the IDE controller to do a disk read will be interpreted and eventually turn into a disk/file-read in Dom0 [qemu-dm runs in Dom0 too]. Interrupts are delivered back to the guest as per the same idea - event channels are used to signal that the thread is now ready to run. I hope this helps. -- Mats> > Hope that helps, > Diwaker > -- > Web/Blog/Gallery: http://floatingsun.net/blog > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users