Gautham Kampalapur Shankar, TLS, Chennai
2007-Jun-05 06:38 UTC
[Xen-devel] about VIRQ & PIRQ
about VIRQ & PIRQ what is VIRQ ?How VIRQ is different from PIRQ ?How VIRQ & PIRQ are related each other ? DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
When save/restore happens at VM_Exit with IDT_vectoring valid,
pending_valid should be set so that resume path can take correct action.
Signed-off-by: Yaozu (Eddie) Dong <eddie.dong@intel.com>
diff -r bd3d6b4c52ec xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c Fri Jun 01 14:50:52 2007 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c Mon Jun 04 23:15:09 2007 +0800
@@ -532,6 +532,7 @@ int vmx_vmcs_save(struct vcpu *v, struct
* never inject when IDT_VECTORING_INFO_FIELD is valid.*/
if ( (ev = __vmread(IDT_VECTORING_INFO_FIELD)) &
INTR_INFO_VALID_MASK )
{
+ c->pending_valid = 1;
c->pending_event = ev;
c->error_code = __vmread(IDT_VECTORING_ERROR_CODE);
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
At 15:23 +0800 on 05 Jun (1181057036), Dong, Eddie wrote:> > When save/restore happens at VM_Exit with IDT_vectoring valid, > pending_valid should be set so that resume path can take correct action.That should be OK - pending_valid is just semantic sugar for the INTR_INFO_VALID_MASK bit of the pending_event field, which we''ve just checked is set. We only need to explicitly set it if we''re fabricating the event from scratch (as in the SVM vintr case). Cheers, Tim. -- Tim Deegan <Tim.Deegan@xensource.com>, XenSource UK Limited Registered office c/o EC2Y 5EB, UK; company number 05334508 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> what is VIRQ ?How VIRQ is different from PIRQ ?How VIRQ & > PIRQ are related each other ?To explain this, we need to understand the entire processing of interrupts and how that relates to the guest kernel. In a normal (bare-metal/non-virtual) system, interrupts are used to "wake up" the kernel when some non-CPU hardware is finished with some activity (such as counting a counter to it''s final count [timer], storing a sector or data to a disk or sending a network packet). Almost all of these events happen completely asynchronously to the execution of instructions in the CPU, and they may well wake the CPU from a HLT instruction (which is the way to say "I''ve got nothing better to do than to wait for the next interrupt"). It gets more complicated in a virtual environment. Let''s say that guest A sends off a packet of network data, then goes to a HLT - which is a "magic" instruction in a virtual environment, and thus tells the hypervisor that "This guest hasn''t got any work to do, let''s run another guest". Let''s now assume that this other guest, Guest B, is doing some pure calculation activity (say calculating the first 5 million positions of PI), so it''s not interacting with any hardware and will run for quite some time without "stopping". Now an interrupt comes in. This interrupt BELONGS to A, but B is currently running. That wouldn''t work very well, right? So the way to solve this is to have the "real" interrupt go to the hypervisor. This is the Physical IRQ or PIRQ. The hypervisor keeps a list of which physical IRQ belongs to which guest(s) and issues the relevant Virtual IRQ to the guest - this is done using an event-channel. Note also that HVM guests are also dealing with physical interrupts by doing a VMExit and then letting the hypervisor take the interrupt as per usual. For the same reason, the physical interrupt may not be for the guest that is currently running. [In fact, in an IO-intensive system, it''s most likely NOT the guest that cuased the interrupt that is active when the interrupt arrives to the processor]. -- Mats> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Gautham Kampalapur Shankar, TLS, Chennai
2007-Jun-05 10:49 UTC
[Xen-devel] FW: about VIRQ & PIRQ
FW: about VIRQ & PIRQ -----Original Message----- From: Gautham Kampalapur Shankar, TLS, Chennai Sent: Tue 6/5/2007 12:08 PM To: xen-devel@lists.xensource.com Subject: about VIRQ & PIRQ what is VIRQ ?How VIRQ is different from PIRQ ?How VIRQ & PIRQ are related each other in xen ? DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> what is VIRQ ?How VIRQ is different from PIRQ ?How VIRQ & PIRQ are > related each other in xen ?Lets take a step back. In Xen, interrupt-like events are carried by "event channels". An event channel is a general mechanism for a domain receiving a notification "something happened on event channel n". That''s all the information an event conveys, it''s up to the domain to figure out what to do next. PIRQs represent physical interrupts from the real hardware. If a domain is controlling a real hardware device (such as a network card) it needs to receive IRQs it generates, just like it would on a native system. Xen allows the domain to bind the IRQ line of that device to an event channel in the guest - this allows the guest to receive "something happened" notifications so that it can handle the device appropriately. This kind of event channel notification is referred to as a PIRQ to show that it comes from a *physical* (not virtual) source. If I recall correctly, PIRQs are mapped one-to-one onto the lower numbered event channels (I''m not sure if this is specific to XenLinux or part of the Xen API). A VIRQ is a interrupt-like event that originates from Xen itself. An example would be notifications from the Xen virtual timer device. Again, the guest sees it as an event channel notification but this time we call it a VIRQ to show that it comes from an entirely *virtual* source. There are actually more variations to event channels: events might also come from another domain we are communicating with, or (I think) from another VCPU in the same domain. Hope this helps, Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Mark Williamson >Sent: 2007年6月6日 0:20 > >If I recall correctly, PIRQs are mapped one-to-one onto the lower >numbered >event channels (I''m not sure if this is specific to XenLinux or part of the >Xen API). >Good explanation, except one point. :-) All event channels are allocated on demand and there''s no one-to-one mapping for even PIRQ. When driver tries to start its irq, a new event port is allocated and then bound to that PIRQ. There does be a one-to-one mapping style, for PIRQ mapped into the IRQ namespace which is shared with DYNIRQ. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mark, [snip]> > If I recall correctly, PIRQs are mapped one-to-one onto the lower numbered > event channels (I''m not sure if this is specific to XenLinux or part of the > Xen API). > > A VIRQ is a interrupt-like event that originates from Xen itself. An example > would be notifications from the Xen virtual timer device. Again, the guest > sees it as an event channel notification but this time we call it a VIRQ to > show that it comes from an entirely *virtual* source.Does this means if hypervisor recieves an interrupt from an external card on the behalf of a domU, it actually buffers it like a an APIC before eventually generating a VIRQ to the respective domU? The above question is more obvious when we have an external hardware device which generates interrupts are a very high rate e.g a busy network card. So, does Xen buffers the recieved IRQs if it is unable to send the IRQ to the correct domU? I hope same holds true while handling interrupts on the behalf of dom0. Or is it that, Xen just forwards the interrupt to dom0 which then handles the actual creation of a VIRQ using event channels to notify a domU? Thank you - --psr> > There are actually more variations to event channels: events might also come > from another domain we are communicating with, or (I think) from another VCPU > in the same domain. > > Hope this helps, > Cheers, > Mark > > -- > Dave: Just a question. What use is a unicyle with no seat? And no pedals! > Mark: To answer a question with a question: What use is a skateboard? > Dave: Skateboards have wheels. > Mark: My wheel has a wheel! > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFGZm36ky6Gd9lpXlERApaLAJ9PHCvWMG8a16m3gNhb2P/dlJMi2QCfbFkN b7sUQ0B9sswcA2gxxsQTdBo=YlzF -----END PGP SIGNATURE----- -- --- pradeep singh rautela "Genius is 1% inspiration, and 99% perspiration" - not me :) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > pradeep singh rautela > Sent: 06 June 2007 09:19 > To: Mark Williamson > Cc: Gautham Kampalapur Shankar, TLS, Chennai; > xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] FW: about VIRQ & PIRQ > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi Mark, > [snip] > > > > If I recall correctly, PIRQs are mapped one-to-one onto the > lower numbered > > event channels (I''m not sure if this is specific to > XenLinux or part of the > > Xen API). > > > > A VIRQ is a interrupt-like event that originates from Xen > itself. An example > > would be notifications from the Xen virtual timer device. > Again, the guest > > sees it as an event channel notification but this time we > call it a VIRQ to > > show that it comes from an entirely *virtual* source. > Does this means if hypervisor recieves an interrupt from an external > card on the behalf of a domU, it actually buffers it like a an APIC > before eventually generating a VIRQ to the respective domU?Yes, essentially so. There is a bitmap for each guest of "pending interrupts", which is read based on an event to the guest.> > The above question is more obvious when we have an external hardware > device which generates interrupts are a very high rate e.g a busy > network card. > > So, does Xen buffers the recieved IRQs if it is unable to send the IRQ > to the correct domU?It is "never unable" to send the IRQ to the guest. The guest may be unable to TAKE the interrupt at this point, but it''s never unable for the hypervisor to "send" the IRQ to the guest. To understand better, have a look at .../xen/arch/x86/irq.c, and in particular the function __do_IRQ_guest().> > I hope same holds true while handling interrupts on the > behalf of dom0. > Or is it that, Xen just forwards the interrupt to dom0 which then > handles the actual creation of a VIRQ using event channels to notify a > domU?I think I''ve told you before, Dom0 is no different from any other domain when it comes to how it interacts with the hypervisor, aside from having a bit set that says "You''re allowed to do things like creating/destroying other guests". Interrupt handling in Dom0 is exactly identical to any other guest - there is nothing in the above irq.c file that says "if (domain is dom0) ..." (in fact, the only domain_id usage is for a printk in the "dump_irqs" function, which is for dumping the current IRQ state on the console when in Xen console-mode. -- Mats> > Thank you > - --psr > > > > > There are actually more variations to event channels: > events might also come > > from another domain we are communicating with, or (I think) > from another VCPU > > in the same domain. > > > > Hope this helps, > > Cheers, > > Mark > > > > -- > > Dave: Just a question. What use is a unicyle with no seat? > And no pedals! > > Mark: To answer a question with a question: What use is a > skateboard? > > Dave: Skateboards have wheels. > > Mark: My wheel has a wheel! > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: http://firegpg.tuxfamily.org > > iD8DBQFGZm36ky6Gd9lpXlERApaLAJ9PHCvWMG8a16m3gNhb2P/dlJMi2QCfbFkN > b7sUQ0B9sswcA2gxxsQTdBo> =YlzF > -----END PGP SIGNATURE----- > -- > --- > pradeep singh rautela > > "Genius is 1% inspiration, and 99% perspiration" - not me :) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/6/07, Petersson, Mats wrote: [snip]> > Does this means if hypervisor recieves an interrupt from an external > > card on the behalf of a domU, it actually buffers it like a an APIC > > before eventually generating a VIRQ to the respective domU? > > > Yes, essentially so. There is a bitmap for each guest of "pending > interrupts", which is read based on an event to the guest. > > > > > The above question is more obvious when we have an external hardware > > device which generates interrupts are a very high rate e.g a busy > > network card. > > > > So, does Xen buffers the recieved IRQs if it is unable to send the IRQ > > to the correct domU? > > It is "never unable" to send the IRQ to the guest. The guest may be > unable to TAKE the interrupt at this point, but it''s never unable for > the hypervisor to "send" the IRQ to the guest.Yes, messed that up here.> > To understand better, have a look at .../xen/arch/x86/irq.c, and in > particular the function __do_IRQ_guest(). > > > > > I hope same holds true while handling interrupts on the > > behalf of dom0. > > Or is it that, Xen just forwards the interrupt to dom0 which then > > handles the actual creation of a VIRQ using event channels to notify a > > domU? > > I think I''ve told you before, Dom0 is no different from any other domain > when it comes to how it interacts with the hypervisor, aside from having > a bit set that says "You''re allowed to do things like > creating/destroying other guests". Interrupt handling in Dom0 is exactly > identical to any other guest - there is nothing in the above irq.c file > that says "if (domain is dom0) ..." (in fact, the only domain_id usage > is for a printk in the "dump_irqs" function, which is for dumping the > current IRQ state on the console when in Xen console-mode.Thank you Mats. Regards - --psr> > -- > Mats > > > > Thank you > > - --psr > > > > > > > > There are actually more variations to event channels: > > events might also come > > > from another domain we are communicating with, or (I think) > > from another VCPU > > > in the same domain. > > > > > > Hope this helps, > > > Cheers, > > > Mark > > > > > > -- > > > Dave: Just a question. What use is a unicyle with no seat? > > And no pedals! > > > Mark: To answer a question with a question: What use is a > > skateboard? > > > Dave: Skateboards have wheels. > > > Mark: My wheel has a wheel! > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > Comment: http://firegpg.tuxfamily.org > > > > iD8DBQFGZm36ky6Gd9lpXlERApaLAJ9PHCvWMG8a16m3gNhb2P/dlJMi2QCfbFkN > > b7sUQ0B9sswcA2gxxsQTdBo> > =YlzF > > -----END PGP SIGNATURE----- > > -- > > --- > > pradeep singh rautela > > > > "Genius is 1% inspiration, and 99% perspiration" - not me :) > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > > > >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFGZsEZky6Gd9lpXlERAhXHAJ98OdKCPTGoi3DeKQgTzgkzK8yH7ACdEaJC 6vBKuDO2Ro5+s/o1jQk7AN4=jN20 -----END PGP SIGNATURE----- -- --- pradeep singh rautela "Genius is 1% inspiration, and 99% perspiration" - not me :) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > > Does this means if hypervisor recieves an interrupt from an external > > > card on the behalf of a domU, it actually buffers it like a an APIC > > > before eventually generating a VIRQ to the respective domU? > > > > Yes, essentially so. There is a bitmap for each guest of "pending > > interrupts", which is read based on an event to the guest. > > > > > The above question is more obvious when we have an external hardware > > > device which generates interrupts are a very high rate e.g a busy > > > network card. > > > > > > So, does Xen buffers the recieved IRQs if it is unable to send the IRQ > > > to the correct domU? > > > > It is "never unable" to send the IRQ to the guest. The guest may be > > unable to TAKE the interrupt at this point, but it''s never unable for > > the hypervisor to "send" the IRQ to the guest. > > Yes, messed that up here.That said, the IRQ upcall isn''t delivered immediately to the guest if the guest isn''t scheduled at the time. The event will be marked pending and the guest should get an upcall from Xen when it''s next scheduled. This is true for dom0 also, since it''s treated in the same way. If the guest has the event channel masked when the event occurs, an upcall will not be made - it''s the responsibility of the guest to check whether an event has occurred whilst the event channel is masked. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,>To understand better, have a look at .../xen/arch/x86/irq.c, and in >particular the function __do_IRQ_guest().But do hvm guests use event channels as used in /xen/arch/x86/irq.c. My thinking was they use emulated pic/apic. ----- Original Message ---- From: "xen-devel-request@lists.xensource.com" <xen-devel-request@lists.xensource.com> To: xen-devel@lists.xensource.com Sent: Wednesday, 6 June, 2007 8:37:57 PM Subject: Xen-devel Digest, Vol 28, Issue 52 Send Xen-devel mailing list submissions to xen-devel@lists.xensource.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel or, via email, send a message with subject or body ''help'' to xen-devel-request@lists.xensource.com You can reach the person managing the list at xen-devel-owner@lists.xensource.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Xen-devel digest..." Today''s Topics: 1. RE: FW: about VIRQ & PIRQ (Petersson, Mats) 2. Re: FW: about VIRQ & PIRQ (pradeep singh rautela) 3. Re: [patch 14/33] xen: xen time implementation (Jeremy Fitzhardinge) 4. Re: troubles using network boot with HVM guest (Guillaume Rousse) 5. Re: troubles using network boot with HVM guest (Tim Deegan) ---------------------------------------------------------------------- Message: 1 Date: Wed, 6 Jun 2007 16:09:06 +0200 From: "Petersson, Mats" <Mats.Petersson@amd.com> Subject: RE: [Xen-devel] FW: about VIRQ & PIRQ To: "pradeep singh rautela" <rautelap@gmail.com>, "Mark Williamson" <mark.williamson@cl.cam.ac.uk> Cc: "Gautham Kampalapur Shankar, TLS, Chennai" <gauthamk@hcl.in>, xen-devel@lists.xensource.com Message-ID: <907625E08839C4409CE5768403633E0B02561DD1@sefsexmb1.amd.com> Content-Type: text/plain; charset=us-ascii> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > pradeep singh rautela > Sent: 06 June 2007 09:19 > To: Mark Williamson > Cc: Gautham Kampalapur Shankar, TLS, Chennai; > xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] FW: about VIRQ & PIRQ > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi Mark, > [snip] > > > > If I recall correctly, PIRQs are mapped one-to-one onto the > lower numbered > > event channels (I''m not sure if this is specific to > XenLinux or part of the > > Xen API). > > > > A VIRQ is a interrupt-like event that originates from Xen > itself. An example > > would be notifications from the Xen virtual timer device. > Again, the guest > > sees it as an event channel notification but this time we > call it a VIRQ to > > show that it comes from an entirely *virtual* source. > Does this means if hypervisor recieves an interrupt from an external > card on the behalf of a domU, it actually buffers it like a an APIC > before eventually generating a VIRQ to the respective domU?Yes, essentially so. There is a bitmap for each guest of "pending interrupts", which is read based on an event to the guest.> > The above question is more obvious when we have an external hardware > device which generates interrupts are a very high rate e.g a busy > network card. > > So, does Xen buffers the recieved IRQs if it is unable to send the IRQ > to the correct domU?It is "never unable" to send the IRQ to the guest. The guest may be unable to TAKE the interrupt at this point, but it''s never unable for the hypervisor to "send" the IRQ to the guest. To understand better, have a look at .../xen/arch/x86/irq.c, and in particular the function __do_IRQ_guest().> > I hope same holds true while handling interrupts on the > behalf of dom0. > Or is it that, Xen just forwards the interrupt to dom0 which then > handles the actual creation of a VIRQ using event channels to notify a > domU?I think I''ve told you before, Dom0 is no different from any other domain when it comes to how it interacts with the hypervisor, aside from having a bit set that says "You''re allowed to do things like creating/destroying other guests". Interrupt handling in Dom0 is exactly identical to any other guest - there is nothing in the above irq.c file that says "if (domain is dom0) ..." (in fact, the only domain_id usage is for a printk in the "dump_irqs" function, which is for dumping the current IRQ state on the console when in Xen console-mode. -- Mats> > Thank you > - --psr > > > > > There are actually more variations to event channels: > events might also come > > from another domain we are communicating with, or (I think) > from another VCPU > > in the same domain. > > > > Hope this helps, > > Cheers, > > Mark > > > > -- > > Dave: Just a question. What use is a unicyle with no seat? > And no pedals! > > Mark: To answer a question with a question: What use is a > skateboard? > > Dave: Skateboards have wheels. > > Mark: My wheel has a wheel! > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: http://firegpg.tuxfamily.org > > iD8DBQFGZm36ky6Gd9lpXlERApaLAJ9PHCvWMG8a16m3gNhb2P/dlJMi2QCfbFkN > b7sUQ0B9sswcA2gxxsQTdBo> =YlzF > -----END PGP SIGNATURE----- > -- > --- > pradeep singh rautela > > "Genius is 1% inspiration, and 99% perspiration" - not me :) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >------------------------------ Message: 2 Date: Wed, 6 Jun 2007 19:44:08 +0530 From: "pradeep singh rautela" <rautelap@gmail.com> Subject: Re: [Xen-devel] FW: about VIRQ & PIRQ To: "Petersson, Mats" <Mats.Petersson@amd.com> Cc: "Gautham Kampalapur Shankar, TLS, Chennai" <gauthamk@hcl.in>, xen-devel@lists.xensource.com, Mark Williamson <mark.williamson@cl.cam.ac.uk> Message-ID: <6bc632150706060714l5ba382a2ra5cbd92d9b7f0494@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/6/07, Petersson, Mats wrote: [snip]> > Does this means if hypervisor recieves an interrupt from an external > > card on the behalf of a domU, it actually buffers it like a an APIC > > before eventually generating a VIRQ to the respective domU? > > > Yes, essentially so. There is a bitmap for each guest of "pending > interrupts", which is read based on an event to the guest. > > > > > The above question is more obvious when we have an external hardware > > device which generates interrupts are a very high rate e.g a busy > > network card. > > > > So, does Xen buffers the recieved IRQs if it is unable to send the IRQ > > to the correct domU? > > It is "never unable" to send the IRQ to the guest. The guest may be > unable to TAKE the interrupt at this point, but it''s never unable for > the hypervisor to "send" the IRQ to the guest.Yes, messed that up here.> > To understand better, have a look at .../xen/arch/x86/irq.c, and in > particular the function __do_IRQ_guest(). > > > > > I hope same holds true while handling interrupts on the > > behalf of dom0. > > Or is it that, Xen just forwards the interrupt to dom0 which then > > handles the actual creation of a VIRQ using event channels to notify a > > domU? > > I think I''ve told you before, Dom0 is no different from any other domain > when it comes to how it interacts with the hypervisor, aside from having > a bit set that says "You''re allowed to do things like > creating/destroying other guests". Interrupt handling in Dom0 is exactly > identical to any other guest - there is nothing in the above irq.c file > that says "if (domain is dom0) ..." (in fact, the only domain_id usage > is for a printk in the "dump_irqs" function, which is for dumping the > current IRQ state on the console when in Xen console-mode.Thank you Mats. Regards - --psr> > -- > Mats > > > > Thank you > > - --psr > > > > > > > > There are actually more variations to event channels: > > events might also come > > > from another domain we are communicating with, or (I think) > > from another VCPU > > > in the same domain. > > > > > > Hope this helps, > > > Cheers, > > > Mark > > > > > > -- > > > Dave: Just a question. What use is a unicyle with no seat? > > And no pedals! > > > Mark: To answer a question with a question: What use is a > > skateboard? > > > Dave: Skateboards have wheels. > > > Mark: My wheel has a wheel! > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > Comment: http://firegpg.tuxfamily.org > > > > iD8DBQFGZm36ky6Gd9lpXlERApaLAJ9PHCvWMG8a16m3gNhb2P/dlJMi2QCfbFkN > > b7sUQ0B9sswcA2gxxsQTdBo> > =YlzF > > -----END PGP SIGNATURE----- > > -- > > --- > > pradeep singh rautela > > > > "Genius is 1% inspiration, and 99% perspiration" - not me :) > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > > > > >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFGZsEZky6Gd9lpXlERAhXHAJ98OdKCPTGoi3DeKQgTzgkzK8yH7ACdEaJC 6vBKuDO2Ro5+s/o1jQk7AN4=jN20 -----END PGP SIGNATURE----- -- --- pradeep singh rautela "Genius is 1% inspiration, and 99% perspiration" - not me :) ------------------------------ Download prohibited? No problem! To chat from any browser without download, Click Here: http://in.messenger.yahoo.com/webmessengerpromo.php _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Koripella Srinivas [mailto:talkwithsrinivas@yahoo.co.in] > Sent: 07 June 2007 03:46 > To: xen-devel@lists.xensource.com; Petersson, Mats; pradeep > singh rautela"; Mark Williamson > Subject: Re: FW: about VIRQ & PIRQ > > Hi, > >To understand better, have a look at .../xen/arch/x86/irq.c, and in > >particular the function __do_IRQ_guest(). > > But do hvm guests use event channels as used in > /xen/arch/x86/irq.c. My thinking was they use emulated pic/apic.That is correct - the HVM guests use a different principle - although there''s still an event-channel for the QEMU to signal to the hypervisor that there''s an interrupt pending so that the hypervisor will "look" at the emulated pic/apic. -- Mats _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > >To understand better, have a look at .../xen/arch/x86/irq.c, and in > > >particular the function __do_IRQ_guest(). > > > > But do hvm guests use event channels as used in > > /xen/arch/x86/irq.c. My thinking was they use emulated pic/apic. > > That is correct - the HVM guests use a different principle - although > there''s still an event-channel for the QEMU to signal to the hypervisor > that there''s an interrupt pending so that the hypervisor will "look" at > the emulated pic/apic.Additionally, HVM guests can make use of Xen event channels if paravirtualised driver support is added to them. I''m not sure how they actually interface with the event channels. For "normal" HVM guests that don''t have any Xen-aware software installed in them this is irrelevant. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel