> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home