[Xen-devel] unsubscribe

["Andrey Kuzmin" <andrey.v.kuzmin@xxxxxxxxx>]

On 3/8/08, xen-devel-request@xxxxxxxxxxxxxxxxxxx
<xen-devel-request@xxxxxxxxxxxxxxxxxxx> wrote:
> 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: MSI and VT-d interrupt remapping (Espen Skoglund)
>    2. RE: Handling VT-d translation faults (Espen Skoglund)
>    3. [PATCH] Fix EDD pointer in int 13h,     fn 48h BIOS call return
>       buffer (Bruce Rogers)
>    4. Re: RE: Re: RE: [Xen-devel] where is the location of
>       definitionof"do_xen_version"? (=?gb2312?B?t7+6o7fl?=)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 7 Mar 2008 15:31:20 +0000
> From: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] MSI and VT-d interrupt remapping
> To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx,    Espen Skoglund
>       <espen.skoglund@xxxxxxxxxxxxx>
> Message-ID: <18385.24520.251144.711784@xxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
>
> [Keir Fraser]
> > On 6/3/08 21:07, "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx> wrote:
> >> If an MSI capable device was able to make use of the above feature,
> >> the device could be set up to generate different interrupts
> >> depending on where the incoming interrupt was to be handled.  For
> >> example, incoming data for a particular guest could trigger an
> >> interrupt on the processor where that guest is running.  Obviously,
> >> a dom0-like backend driver would not be involved in the actual
> >> event delivery in these situations.  The event would be delivered
> >> directly to the frontend.
> >>
> >> The necessary changes would enable a device driver for an MSI capable
> >> device to allocate a range of pirqs and bind these to different
> >> frontends.
>
> > The only tricky bit here is deciding what the interface should be to
> > the hypervisor to specify these allocation constraints.
>
> > Another thought though: there's no good reqson for Xen to scatter
> > its irq-vector allocations across the vector space. That's a
> > holdover from classic-Pentium-era systems, which could lose
> > interrupts if too many got 'queued up' at any single priority
> > level. So we could actually allocate our vectors contiguously,
> > making it much more likely that you could successfully allocate a
> > contiguous range even without remapping.
>
> > However, I guess you want to be able to specify different target
> > APICs for different vectors too, so again it comes back to: what
> > should the guest interface to irq-remapping hardware be?
>
> Right.  The reason for bringing up this suggestion now rather than
> later is because MSI support has not yet found its way into mainline.
> Whoever decides on the interface used for registering MSI and MSI-X
> interrupts might want to take multi-message MSIs into account as well.
>
> I do not think explicitly specifying destination APIC upon allocation
> is the best idea.  Setting the affinity upon binding the interrupt
> like it's done today seems like a better approach.  This leaves us
> with dealing with the vectors.
>
> My initial thought was to make use of the new msix_entries[] field in
> the xen_pci_op structure.  This field is already used as an in/out
> parameter for allocating MSI-X interrupts.  The pciback_enable_msi()
> function can then attempt to allocate multiple interrupts instead of a
> single one, and return the allocated vectors.
>
> The current MSI patchset also lacks a set_affinity() function for
> changing the APIC destination similar to what is done for, e.g.,
> IOAPICs.  Also similar to IOAPICs, the MSI support should have
> something like the io_apic_write_remap_rte() for rewriting the
> interrupt remapping table when enabled.
>
> A special case must exist when setting the interrupt affinity for
> multiple-message enabled MSI devices.  There probably should exist
> some magic in the set_affinity() function for handling this properly.
> That is, setting affinity for the whole group of MSI interrupts does
> not make all that much sense.  It makes more sense when one can set
> the per-interrupt affinity through the interrupt remapping table.
>
> It should be evident by now that my suggestions for deciding upon an
> interface and implementation of it is rather fluffy; borderlining
> non-existent.  This is partly because I'm talking about not yet
> existing MSI support, but mainly because I'm still new to Xen
> internals.  Nonetheless, I believe it would be good for people working
> on MSI support to take multi-message and interrupt remapping into
> account as well.
>
>       eSk
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 7 Mar 2008 16:20:16 +0000
> From: Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
> Subject: RE: [Xen-devel] Handling VT-d translation faults
> To: "Han, Weidong" <weidong.han@xxxxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Message-ID: <18385.27456.765352.154047@xxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
>
> [Weidong Han]
> > Espen Skoglund wrote:
> >> o The fault handler doesn't actually do much right now.  It just
> >> clears out the fault queue and prints out warnings.  I can only
> >> suspect that some more code to handle faults more gracefully are
> >> somewhere in the pipeline.
> >>
> >> The question is what the plans for dealing with DMA translation
> >> faults are (i.e., due to accessing unmapped memory or writing to
> >> read-only mappings).  At the very least the associated driver
> >> should have the possibility to somehow be notified about failed
> >> transactions due to translation faults.  Is something like this
> >> being planned for?
> >>
>
> > Pls refer to 3.5 setion of VT-d spec. DMA requests that result in
> > remapping faults must be blocked by hardware. The exact method of
> > DMA blocking is implementation-specific. Faulting DMA write / read
> > requests may be handled in much the same way as hardware handles
> > write requests to non-existent memory. So I think our fault handler
> > that clears fault queue and prints out warnings is enough.
>
> Yes, I'm aware that faulting DMA remapping transactions are blocked by
> the hardware.  However, I'm concerned that faulting transactions can
> cause malfunctions if not detected by the system.  Sure, for read
> requests on PCIe the device will notice the error in the completion
> status and can handle it apropriately.  But how about write requests?
> (I don't know if PCIe device will be notified of memory write
> failures.)  And how about requests from non-PCIe devices?
>
> It may be the case that all DMA translation faults are entirely the
> result of device drivers having screwed up and shot themselves in the
> foot, and that they should be allowed to repeatedly do so until their
> leg falls off.  However, I'm not convinced that faulting DMA
> translations are always the cause of faulty drivers, in particular if
> one starts allowing frontends to more directly talk to the device.
>
> If DMA translation faults can always safely be ignored then I'm happy
> to accept that.  On the other hand, a device repeatedly raising
> translation faults is surely doing something wrong, and bringing it
> down might be a good idea.
>
> Anyhow, if all DMA translation faults can be ignored, why then bother
> enabling faults in the context entries in the first place?
>
>       eSk
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 07 Mar 2008 12:26:16 -0700
> From: "Bruce Rogers" <brogers@xxxxxxxxxx>
> Subject: [Xen-devel] [PATCH] Fix EDD pointer in int 13h,      fn 48h BIOS
>       call return buffer
> To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
> Message-ID: <47D13468020000480004B2FA@xxxxxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=US-ASCII
>
> I ran into this when I was reviewing what was outstanding to get NetWare to
> run fully virtualized.
>
> The BIOS emulator code has the segment and offset backward in the returned
> buffer for the int 13h, fn 48h BIOS call.
>
> BTW: This is fixed in current Bochs emulator upstream code.
>
> Signed-off-by: Bruce Rogers <brogers@xxxxxxxxxx>
>
> diff -r 59b8768d0d0d tools/firmware/rombios/rombios.c
> --- a/tools/firmware/rombios/rombios.c  Wed Mar 05 11:18:25 2008 +0000
> +++ b/tools/firmware/rombios/rombios.c  Fri Mar 07 05:36:51 2008 -0700
> @@ -779,8 +779,8 @@ typedef struct {
>      Bit32u  sector_count1;
>      Bit32u  sector_count2;
>      Bit16u  blksize;
> +    Bit16u  dpte_offset;
>      Bit16u  dpte_segment;
> -    Bit16u  dpte_offset;
>      Bit16u  key;
>      Bit8u   dpi_length;
>      Bit8u   reserved1;
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 8 Mar 2008 11:01:31 +0800
> From: "=?gb2312?B?t7+6o7fl?=" <fanghaifeng@xxxxxxxxxx>
> Subject: Re: RE: Re: RE: [Xen-devel] where is the location of
>       definitionof"do_xen_version"?
> To: "Shan, Haitao" <haitao.shan@xxxxxxxxx>
> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
> Message-ID: <200803081101310311830@xxxxxxxxxx>
> Content-Type: text/plain; charset="gb2312"
>
> thank you very much for your replying!
>
> and can you tell why xen do it in this way?
>
> and what is the "__guest_handle_ " ?
>
> thanks again.
>
> 2008-03-08
>
>
>
> ææå
>
>
>
> åääï Shan, Haitao
> åéæéï 2008-03-07  20:54:54
> æääï fanghaifeng@xxxxxxxxxx; xen-devel
> æéï
> äéï RE: Re: RE: [Xen-devel] where is the location of
> definitionof"do_xen_version"?
>
> Xen/common/kernel.c
> #define DO(fn) long do_##fn
>
> DO(xen_version) )(int cmd, XEN_GUEST_HANDLE(void) arg)
>
>
>
>
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of ææå
> Sent: 2008å3æ7æ 18:50
> To: xen-devel
> Subject: Fw: Re: RE: [Xen-devel] where is the location of
> definitionof"do_xen_version"?
>
>
>
> 2008-03-07
>
>
>
> ææå
>
>
>
> åääï ææå
> åéæéï 2008-03-07 18:49:08
> æääï Zheng, Shaohui
> æéï
> äéï Re: RE: [Xen-devel] where is the location of definition
> of"do_xen_version"?
>
> thanks for you!
> but the function you found is running in the user-space.
> what i need is the function as a hypercall.
>
>
> 2008-03-07
>
>
>
> ææå
>
>
>
> åääï Zheng, Shaohui
> åéæéï 2008-03-07  17:46:52
> æääï fanghaifeng@xxxxxxxxxx; xen-devel
> æéï
> äéï RE: [Xen-devel] where is the location of definition of"do_xen_version"?
> tools/libxc/xc_private.h
> the start line  is 88.
> 88 static inline int do_xen_version(int xc_handle, int cmd, void *dest)
>  89 {
>  90     DECLARE_HYPERCALL;
>  91
>  92     hypercall.op     = __HYPERVISOR_xen_version;
>  93     hypercall.arg[0] = (unsigned long) cmd;
>  94     hypercall.arg[1] = (unsigned long) dest;
>  95
>  96     return do_xen_hypercall(xc_handle, &hypercall);
>  97 }
> Ctags can help you find the definition a function.
> Just run the following commands.
> cd xen-src-dir
> ctags -R
> vim -t do_xen_version
> then you got it.
> --
> Best Regards
> Shaohui
> ________________________________________
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of ææå
> Sent: 2008å3æ7æ 17:46
> To: xen-devel
> Subject: [Xen-devel] where is the location of definition of
> "do_xen_version"?
> hi, my friends:
>
> Currently, i am studying the way of hypercall's implementation.
> i have already known the flow of hypercall's execuation, and i decided to
> add a new hypercall into the Xen.
> first, i want to know the detail of one hypercall function, for example,
> "do_xen_version", but i can not find
> the location of definition of "do_xen_version". who can help me?
>
> i have get some resualts as follows:
>
> [root@vt-0 xen-3.1.0-src]# find ./ -name "*.*" | xargs grep "do_xen_version"
> ./xen/include/xen/hypercall.h:do_xen_version(
> Binary file ./xen/common/built_in.o matches
> Binary file ./xen/common/kernel.o matches
> ./xen/arch/x86/x86_32/entry.S:        .long do_xen_version
> ./xen/arch/x86/x86_32/entry.S:        .byte 2 /* do_xen_version       */
> Binary file ./xen/arch/x86/x86_32/built_in.o matches
> Binary file ./xen/arch/x86/x86_32/entry.o matches
> ./xen/arch/x86/x86_64/entry.S:        .quad do_xen_version
> ./xen/arch/x86/x86_64/entry.S:        .byte 2 /* do_xen_version       */
> Binary file ./xen/arch/x86/built_in.o matches
> Binary file ./xen/arch/x86/hvm/hvm.o matches
> Binary file ./xen/arch/x86/hvm/built_in.o matches
> ./xen/arch/ia64/linux-xen/entry.S:      data8 do_xen_version
> ./xen/arch/powerpc/powerpc64/hypercall_table.S:        .quad do_xen_version
> Binary file ./dist/install/boot/xen-syms-3.1.0 matches
> ./tools/libxc/xc_private.c:    rc = do_xen_version(xc_handle, cmd, arg);
> ./tools/libxc/xc_private.h:static inline int do_xen_version(int xc_handle,
> int cmd, void *dest)
>
> but the "do_xen_version" is not in those above.
>
> thanks a lots.
>
> www.ict.ac.cn
> 2008-03-07
> ________________________________________
> ææå
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.xensource.com/archives/html/xen-devel/attachments/20080308/dc315ac4/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 37, Issue 40
> *****************************************
>


-- 
Regards,
Andrey

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel