> -----Original Message-----
> From: Koripella Srinivas [mailto:talkwithsrinivas@xxxxxxxxxxx]
> Sent: 06 June 2007 06:32
> To: Petersson, Mats
> Subject: Re: FW: about VIRQ & PIRQ (Petersson, Mats)
>
> Hi Mats,
>
> Does that mean that whenever an interrupt comes from a
> physical device all the hvm guests should be suspended?
Depends on how you define suspended.
The interrupt will cause a VMExit, which means that the hypervisor will get to
run for a little bit. It then takes the interrupt and does whatever hypervisor
action based on the interrupt. If this means that a guest waiting for an
interrupt is now runnable, then the scheduler is called and the scheduler
decides which guest to run from thereon.
Suspended to me has different meanings depending on what the context is - a VM
can be suspended in a "scheduler sense", but you can also have a "machine
suspend", which is what happens for example in a laptop when you close the lid.
--
Mats
>
> thanks
>
>
> ----- Original Message ----
> From: "xen-devel-request@xxxxxxxxxxxxxxxxxxx"
> <xen-devel-request@xxxxxxxxxxxxxxxxxxx>
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Sent: Tuesday, 5 June, 2007 5:29:00 PM
> Subject: Xen-devel Digest, Vol 28, Issue 38
>
>
> Send Xen-devel mailing list submissions to
> xen-devel@xxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxx
>
> You can reach the person managing the list at
> xen-devel-owner@xxxxxxxxxxxxxxxxxxx
>
> 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. FW: about VIRQ & PIRQ (Gautham Kampalapur Shankar, TLS, Chennai)
> 3. Re: Data broken during FTP test (Kasai Takanori)
> 4. [PATCH] [ACM] Python-to-C Interface for new ACM hypercalls
> (Stefan Berger)
> 5. Set cpu_weight and cpu_cap at boot time (Dominik Klein)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Jun 2007 12:44:39 +0200
> From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
> Subject: RE: [Xen-devel] FW: about VIRQ & PIRQ
> To: "Gautham Kampalapur Shankar, TLS, Chennai" <gauthamk@xxxxxx>,
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Message-ID:
> <907625E08839C4409CE5768403633E0B02561DB9@xxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
>
> > 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
> >
> >
> >
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 Jun 2007 16:19:13 +0530
> From: "Gautham Kampalapur Shankar, TLS, Chennai" <gauthamk@xxxxxx>
> Subject: [Xen-devel] FW: about VIRQ & PIRQ
> To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
> Message-ID:
>
> <D309264CD3651841AA75658A61044758AC48B6@xxxxxxxxxxxxxxxxxxxxxx
> RP.HCL.IN>
>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL:
> http://lists.xensource.com/archives/html/xen-devel/attachments
> /20070605/f464bda5/attachment.html
> -------------- next part --------------
> 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.
>
> --------------------------------------------------------------
> ---------------------------------------------------------
>
> ------------------------------
>
> Message: 3
> Date: Tue, 5 Jun 2007 20:00:47 +0900
> From: "Kasai Takanori" <kasai.takanori@xxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] Data broken during FTP test
> To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, "Keir Fraser"
> <Keir.Fraser@xxxxxxxxxxxx>
> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
> Message-ID: <048f01c7a760$caa9e7a0$dab2220a@VF03007L>
> Content-Type: text/plain; format=flowed; charset="iso-2022-jp";
> reply-type=response
>
> Hi All,
>
> We are investigating the problem that data was broken during FTP test.
>
> It did not reproduce it in the latest changeset.
> (xen-unstable.hg: cs15072)
>
> We tested other changesets.
> The test result is as follows.
>
> version | result
> -----------------------+---------------
> xen-3.0.3-testing.hg | Broken
> xen-3.0.4-testing.hg | Not Broken
> xen-3.1-testing.hg | Not Broken
>
> Therefore, it seems that it is corrected between from 3.0.3 to 3.0.4.
> We will investigate by which changeset this problem is corrected.
>
> Best Regards,
>
> --
> Takanori Kasai
>
>
> ----- Original Message -----
> From: "Kasai Takanori" <kasai.takanori@xxxxxxxxxxxxxx>
> To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>; "Keir Fraser"
> <Keir.Fraser@xxxxxxxxxxxx>
> Cc: "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, May 24, 2007 8:04 PM
> Subject: Re: [Xen-devel] Data broken during FTP test
>
>
> > Hi All,
> >
> > I'm sorry the mistake was found in mail.
> > It is a mistake of not DomVTi but DomVTx.
> >
> > Best Regards,
> >
> > --
> > Takanori Kasai
> >
> > ----- Original Message -----
> > From: "Kasai Takanori" <kasai.takanori@xxxxxxxxxxxxxx>
> > To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>; "Keir Fraser"
> > <Keir.Fraser@xxxxxxxxxxxx>
> > Cc: "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
> > Sent: Thursday, May 24, 2007 6:33 PM
> > Subject: Re: [Xen-devel] Data broken during FTP test
> >
> >
> >> Hi Ian and Keir,
> >>
> >> I'm sorry for delaying response.
> >>
> >>
> >>>> Can you reproduce if you uninstall the RHEL5 xen/kernel
> and xen tools
> >>>> and libs RPMs and then install binaries built from xen-unstable?
> >>>
> >>> We will reproduce it with xen-unstable.hg.
> >>
> >> We tested it with the same machine.
> >> The environment is as follows.
> >>
> >> Xen :
> >> - xen-unstable.hg: cs15072
> >> NICs :
> >> - Broadcom Corporation NetXtreme BCM5715 Gigabit Ethernet (rev a3)
> >> - Intel Corporation 82545GM Gigabit Ethenet Controller (rev 04)
> >> Guests :
> >> - DomU
> >> - DomVTi(RHEL5GA)
> >> - DomVTi(RHEL5GA) + PV_ON_HVM(VNIF)
> >> Others:
> >> - SG and TSO flag: ENABLE
> >> - Memory
> >> ・Domain0 : 1GByte
> >> ・Guest Domains : 2GByte
> >>
> >> The test result was not reproduced as follows.
> >>
> >> | Broadcom | Intel
> >> ----------------------------+---------------+---------------
> >> DomU | Not broken | Not broken
> >> DomVTi(RHEL5GA) | Not broken | Not broken
> >> DomVTi(RHEL5GA)+VNIF | Not broken | Not broken
> >>
> >> Next, the tg3 driver and the e1000 driver were replaced
> with RHEL5GA.
> >> However, the result was not reproduced similarly.
> >>
> >> Is there a correction related to this problem since xen3.0.3?
> >>
> >> Best Regards,
> >>
> >> --
> >> Takanori Kasai
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 05 Jun 2007 07:07:07 -0400
> From: Stefan Berger <stefanb@xxxxxxxxxx>
> Subject: [Xen-devel] [PATCH] [ACM] Python-to-C Interface for new ACM
> hypercalls
> To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
> Message-ID: <1181041627.7754.2.camel@xxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
>
> This patch provides an interface for using recently-added Xen
> functionality from python.
>
> Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: xend-xspolicy-xapi-if.diff
> Type: text/x-patch
> Size: 4979 bytes
> Desc: not available
> Url :
> http://lists.xensource.com/archives/html/xen-devel/attachments
> /20070605/d89e5bc3/xend-xspolicy-xapi-if.bin
>
> ------------------------------
>
> Message: 5
> Date: Tue, 05 Jun 2007 13:35:01 +0200
> From: Dominik Klein <dk@xxxxxxxxxxxxxxxx>
> Subject: [Xen-devel] Set cpu_weight and cpu_cap at boot time
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Message-ID: <46654A65.2080902@xxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> Hi
>
> "xm create --help_config" gives:
> ...
> cpu_cap=CAP Set the maximum amount of cpu.
> CAP is a percentage that fixes the
> maximum amount
> of cpu.
> cpu_weight=WEIGHT Set the cpu time ratio to be allocated
> to the domain.
> ...
>
> As it does not work I looked at the py Files and found this:
>
> /usr/lib/python/xen/xend/XendConfig.py :
> ...
> # List of legacy configuration keys that have no equivalent in the
> # Xen API, but are still stored in XendConfig.
> LEGACY_UNSUPPORTED_BY_XENAPI_CFG = [
> # roundtripped (dynamic, unmodified)
> 'shadow_memory',
> 'security',
> 'vcpu_avail',
> 'cpu_weight',
> 'cpu_cap',
> 'features',
> # read/write
> 'on_xend_start',
> 'on_xend_stop',
> # read-only
> 'domid',
> 'start_time',
> 'cpu_time',
> 'online_vcpus',
> # write-once
> 'cpu',
> 'cpus',
> ]
> ...
>
> So it looks like it cannot work yet. Are there any plans to
> change/fix this?
>
> This is xen 3.1.0
>
> Regards
> Dominik
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 28, Issue 38
> *****************************************
>
>
>
> ________________________________
>
> Here’s a new way to find what you're looking for - Yahoo!
> Answers
> <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.ya
> hoo.com/>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home