similar to: Patch series for IGD passthrough

The OpRegion shouldn''t be mapped 1:1 because the address in the host can''t be used in the guest directly. This patch traps read and write access to the opregion of the Intel GPU config space (offset 0xfc). To work correctly this patch needs a change in hvmloader. HVMloader will allocate 2 pages for the OpRegion and write this address on the config space of the Intel GPU. Qemu

The i915 driver probes chip version through PCH ISA bridge device / vendor ID. Previously, the PCH ISA bridge is exposed as PCI-PCI bridge in qemu-xen-trad, which breaks the assumption of the driver. This change fixes the issue by correctly exposing the ISA bridge to domU. Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net> Tested-by: Rui Guo <firemeteor@users.sourceforge.net>

Hi, I have just applied IGD VGA Passthrough patches to Xen 4.4-unstable changeset 27238. Please refer to the 2 attached patches. 1. [Xen-devel] [PATCH 2/3] V4 qemu-xen-trad: Correctly expose PCH ISA bridge for IGD passthrough Link: http://lists.xenproject.org/archives/html/xen-devel/2013-06/msg01720.html 2. [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci

Hi, I have just applied IGD VGA Passthrough patches to Xen 4.4-unstable changeset 27238. Please refer to the 2 attached patches. 1. [Xen-devel] [PATCH 2/3] V4 qemu-xen-trad: Correctly expose PCH ISA bridge for IGD passthrough Link: http://lists.xenproject.org/archives/html/xen-devel/2013-06/msg01720.html 2. [Xen-devel] [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci

This is hvmloader part of the change that gets rid of the resource conflict warning in the guest kernel. The OpRegion may not always be page aligned. As a result one extra page is required to fully accommodate the OpRegion in that case. Just reserve one more page here. Signed-off-by: Timothy Guo <firemeteor@users.sourceforge.net> diff -r 11b4bc743b1f tools/firmware/hvmloader/e820.c ---

This is a way to create virtio based devices from user space. This is the background for this patch: We have some images works fine under qemu, we'd like to also run the same image on Google Cloud. Currently Google Cloud doesn't support virtio-vga. I had a patch to create a virtio-vga from kernel directly: https://www.spinics.net/lists/dri-devel/msg248573.html Then I got feedback from

This is a way to create virtio based devices from user space. This is the background for this patch: We have some images works fine under qemu, we'd like to also run the same image on Google Cloud. Currently Google Cloud doesn't support virtio-vga. I had a patch to create a virtio-vga from kernel directly: https://www.spinics.net/lists/dri-devel/msg248573.html Then I got feedback from

On Wed, Apr 29, 2020 at 08:59:18PM -0700, lepton wrote: > On Wed, Apr 29, 2020 at 4:58 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > > 3) Need to be verbose on how the vring processing work in the commit log of > > > patch 1 > > > > Ecven better a file documenting the interface somewhere in > > Documentation/ > I put a uvirtio-vga.c

Hi developers, I met some domU issues and the log suggests missing interrupt. Details from here: http://www.gossamer-threads.com/lists/xen/users/263938#263938 In summary, this is the suspicious log: (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 I''ve checked the code in question and found that mode 3 is an ''reserved_1'' mode. I want to trace down the source of this

Dear group, Here is my function: #return the daily PL for day y PLDaily<-function(x,y) { #find elements in my directory with "LSCPos" in the name, keep the numeric part in the name and #create a list l<-gsub("\\D","",dir()[grep("LSCPos",dir())]) #select in the list the desired elements

Dear all, I have divided two vectors: Np.occup97.98<- as.data.frame(cbind(site = levels(sums$site), Np.occup97.98 = sums$Ant.Nptrad97.98/Ant.trad$Ant.trad97.98)) > Np.occup97.98 site Np.occup97.98 1 erken97 0.342592592592593 2 erken98 0.333333333333333 3 rormyran 0.48471615720524 4 valkror 0.286026200873362 However, at a later stage of the analysis I want >

LLVM_DEFINITIONS used to be defined as set(LLVM_DEFINITIONS "-D__STDC_LIMIT_MACROS" "-D__STDC_CONSTANT_MACROS") Now it is defined as set(LLVM_DEFINITIONS " -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS") (note that it is no longer a cmake list but a string, and the string contains a leading space!) This causes CMake 3.1 to emit g++ -D

I am currently setting up my Module with module->setTargetTriple(llvm::sys::getProcessTriple() #ifdef _WIN32 + "-elf" #endif ); And my ExecutionEngine with llvm::EngineBuilder(std::move(module)) .setErrorStr(&err) .setMCPU(llvm::sys::getHostCPUName())

I made this change (not specifically changing from a list to a string, but changing from a hardcoded value to the value that was actually decided by cmake), and I checked that it works with cmake 2.8.12.2 which is the minimum version set in CMakeLists.txt. So if it doesn’t work with cmake 3.1/3.2 then that looks like something new that was introduced after 2.8.12.2. I’ll have a look at this

I encountered a new build failure (r227128) on my nightly build of LLVM for MinGW: FAILED: cmd.exe /c cd . && D:\MinGW\x86_64-4.9.1-release-posix-seh-rt_v3-rev0\mingw64\bin\c++.exe -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=gnu++11 -g

On Tue, Jan 27, 2015 at 10:02 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Adding -D__MSVCRT_VERSION__=0x900 (or higher) to CMAKE_CXX_FLAGS and > -lmsvcr90 (or higher) to CMAKE_CXX_STANDARD_LIBRARIES appears to work. > -lmsvcrt80 does not work, contrary to the comment on the MinGW bug tracker. > However, if you do not

Hi Chris and everyone else, I just noticed that some of my builds broke due to commit 280013, as LLVM_INCLUDE_DIRS was renamed to LLVM_INCLUDE_DIR. In and of itself, not much of an issue as the fix is just to remove one character (in a couple of places). However, I would like to discuss if this rename is desirable at all. Sure, in-tree LLVM_INCLUDE_DIR is used everywhere, however not providing an

Both Release and $CONFIG tblgen are built but the Release one is always used. At least with Visual C++ the Release tblgen is much faster than the Debug one. 2015-05-29 9:37 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > Do they really allways put them into Release/bin or rather $<CONFIG>/bin? > > > > -- >

Yes, that's the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is built in Release in addition to whatever /property:Configuration= is. 2015-05-29 10:03 GMT+03:00 Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>: > That it’s faster is no surprise. Is the Release tblgen even built when > you build in Debug mode? Otherwise this

Indeed, mingw and pthreads have C++11 atomics, so building clang (with atomics) should be possible even in cross compilation. I have no idea what is the win from *not* using winpthreads, it is one small DLL file with BSD license. For context (does not matter to mingw as host for buiilding clang but matters for clang running with mingw environment), clang TLS implementation is not same as mingw so