search for: subarchs

Thank you for the feedback. > How is this going to work with --target-subarchs? Is there going to be a --no-target-subarchs flag to disable subarchs? What will the semantics of this be, exactly? The large number of subarchs expected makes an inclusive only flag desirable and an exclusive flag impractical. Also, since subarchs will age more quickly than archs, who knows w...

...ferent flags to provide a list of subarchitectures. For example, cuda clang repeats the flag “--cuda-gpu-arch=sm_35 --cuda-gpu-arch=sm_50” and HCC uses “--amdgpu-target=gfx701 --amdgpu-target=gfx802”. We propose a common clang flag to provide a list of target subarchitectures called “target-subarchs”. For example, --target-subarchs=sm_35,sm_50,gfx701,gfx802 In discussions with HCC and OpenMP maintainers, we believe a new flag name would have these requirements: end in “s” because it is a list; not have vendor specific names like cuda and amd; not contain “gpu” because offloadin...

Looks like the subarch tree has been checked in. Does this mean 3.0.1 has been pushed out to include more? Or do we release 3.0.1 once the new tree is fully tested? Jun --- Intel Open Source Technology Center ---- From: xen-changelog-bounces@lists.xensource.com [mailto:xen-changelog-bounces@lists.xensource.com] On Behalf Of Xen patchbot -unstable Sent: Monday, January 30, 2006 4:08 PM To:

A brave attempt to be rid of an unnecessary subarch hook and clean things up a bit. First, all subarches use IRQ-2 as a cascade IRQ. So do that in the common code. Second, there is no need for a pre_intr_init_hook. We can set up the interrupt gates at any time, as this doesn't touch any real hardware, just the processor gates. Now the subarch code still needs to setup the appropriate irq

A brave attempt to be rid of an unnecessary subarch hook and clean things up a bit. First, all subarches use IRQ-2 as a cascade IRQ. So do that in the common code. Second, there is no need for a pre_intr_init_hook. We can set up the interrupt gates at any time, as this doesn't touch any real hardware, just the processor gates. Now the subarch code still needs to setup the appropriate irq

> On Tue, 2006-07-18 at 00:00 -0700, Chris Wright wrote: > > plain text document attachment (i386-setup) > > Implement the start-of-day subarchitecture setup hooks for booting on > > Xen. Add subarch macros for determining loader type and initrd > > location. > > > diff -r a5848bce3730 arch/i386/kernel/setup.c > > --- a/arch/i386/kernel/setup.c Thu Jun 22

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths

Unlike full virtualization in which the virtual machine provides the same platform interface as running natively on the hardware, paravirtualization requires modification to the guest operating system to work with the platform interface provided by the hypervisor. Xen was designed with performance in mind. Calls to the hypervisor are minimized, batched if necessary, and non-critical codepaths

Add one more MMU hook to the sub-arch layer. update_mmu_cache() - already defined. This is conveniently used to indicate NP->P transitions which should be reflected in an external TLB, and serves to indicate all points where the page tables must be synchronized. Required for lazy updates in shadow mode. There is only one case where an extra flush is needed, in the i386 specific page fault

Add one more MMU hook to the sub-arch layer. update_mmu_cache() - already defined. This is conveniently used to indicate NP->P transitions which should be reflected in an external TLB, and serves to indicate all points where the page tables must be synchronized. Required for lazy updates in shadow mode. There is only one case where an extra flush is needed, in the i386 specific page fault

i386 Transparent paravirtualization subarch patch #5 This change encapsulates descriptor and task register management. Diffs against: 2.6.13-rc4-mm1 Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/desc.h =================================================================== --- linux-2.6.13.orig/include/asm-i386/desc.h 2005-08-08 17:31:59.000000000 -0700

i386 Transparent paravirtualization subarch patch #5 This change encapsulates descriptor and task register management. Diffs against: 2.6.13-rc4-mm1 Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/desc.h =================================================================== --- linux-2.6.13.orig/include/asm-i386/desc.h 2005-08-08 17:31:59.000000000 -0700

The attached re-enables the pygrub build and fixes the build with older e2fsprogs (tested on RHEL4 with e2fsprogs-1.35 and rawhide with e2fsprogs-1.38) Signed-off-by: Jeremy Katz <katzj@redhat.com> Jeremy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hello LLVMdev!! Yesterday I posted a patch request to the llvm-commits list requesting that someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get any response so I wondered whether I should have posted to this list instead. My story is as follows: we are trying to get lldb/llvm support for CSRs range of Kalimba DSPs. Eventually we are planning to hire someone to

On UML: the klibc architecture is the underlying architecture, so set KLIBCARCH to SUBARCH. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 018604e070e143657abcf0cb256a1e2dda205d97 tree 1b853903ca6af49d9f437cfd694aec61ef1d488e parent baacd5d81ff7151e8df3893850ec363441886a1e author H. Peter Anvin <hpa at zytor.com> Mon, 15 May 2006 21:25:33 -0700 committer H. Peter Anvin

Hi, Keir, Any comments upon following patch? ;-) We need it to further check in a specific configuration file (likely xen0_defconfig_ia64tiger) later to run xen on IA64 tiger box. Currently we have no generic one for all IA64 boxes. Let''s know if better way to do it. Currently custom with tiger box can only get that file out of the tree. Thanks, Kevin >-----Original Message-----

Folks, OLS is fast approaching. There is a session on virtualization at the Kernel Summit, with Keir and Zach invited, which will probably last an hour(?). There is also a Xen BoF currently scheduled (Thursday, 7/20, 7:00PM) which will cover Xen specific issues. And there are approximately 3 or 4 paper presentations on related subjects. None of the above are going to allow for adequate time to

> On Sep 13, 2015, at 11:04 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > > On Thu, Sep 10, 2015 at 1:55 AM, Khem Raj via Syslinux > <syslinux at zytor.com> wrote: >> We can let compiler driver pass the right options to preprocessor after >> processing -Mxy options, right now its bypassing the gcc driver and >> handing them straight to cpp >>

Well, it seems to be about time to have this conversation again. A rough overview of the previous thread and requirements is: 1. bzImage would not be a bare ELF file, but it would contain an ELF header+file within it 2. We need some way to add extra ELF notes into that ELF file 3. We use a "paravirtualized" bootloader type, with some other field to determine which

Well, it seems to be about time to have this conversation again. A rough overview of the previous thread and requirements is: 1. bzImage would not be a bare ELF file, but it would contain an ELF header+file within it 2. We need some way to add extra ELF notes into that ELF file 3. We use a "paravirtualized" bootloader type, with some other field to determine which