search for: tcg

...expensive work out of sight. It might not be a pretty >> idea, but LLVM does generate some very tight code :) It's an experiment - >> humour me... > Well, but I still don't get the reason why you need to pin (some) > internal QEMU state variables to fixed registers? > TCG seperates the guest (ARM) code into blocks - my front end translates these to LLVM IR for LLVM to translate to x86. The assumption is that LLVM will produce a better translation than TCG*. At some future point the TCG-generated native block is replaced by the LLVM's, and as such it needs t...

...8:11:30PM +0200, Jan Walzer wrote: >>>>>> Hi Lists, >>>>>> >>>>>> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. >>>>>> >>>>>> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu >>>>>> when starting an instance, as without that, it will only use one thread >>>>>> and hence of limited/no use. >>>>>> >>>>>> The problem is, that libvirt itself, passes “-machine q35,accel...

...: >>> On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: >>>> Hi Lists, >>>> >>>> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. >>>> >>>> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu >>>> when starting an instance, as without that, it will only use one thread >>>> and hence of limited/no use. >>>> >>>> The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to >>>> qemu,...

Hi Andrew, On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery <andrew at aj.id.au> wrote: > TCG seperates the guest (ARM) code into blocks - my front end translates > these to LLVM IR for LLVM to translate to x86.  The assumption is that LLVM > will produce a better translation than TCG*. At some future point the > TCG-generated native block is replaced by the LLVM's, and as such...

...rtions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index ae676c4..eb0e493 100644 --- a/configure.ac +++ b/configure.ac @@ -797,16 +797,16 @@ working. AC_MSG_FAILURE([$QEMU version must be >= 1.0.]) fi - AC_MSG_CHECKING([that $QEMU -nographic -machine accel=kvm:tcg -device ? works]) - if $QEMU -nographic -machine accel=kvm:tcg -device \? >&AS_MESSAGE_LOG_FD 2>&1; then + AC_MSG_CHECKING([that $QEMU -display none -machine accel=kvm:tcg -device ? works]) + if $QEMU -display none -machine accel=kvm:tcg -device \? >&AS_MESSAGE_LOG_FD...

...el P. Berrangé <berrange@redhat.com> wrote: > On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: >> Hi Lists, >> >> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. >> >> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu >> when starting an instance, as without that, it will only use one thread >> and hence of limited/no use. >> >> The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to >> qemu, which is a different parameter, that con...

This patch adds TCG BIOS extensions to the high memory area along with some often-used libc utility functions. The TCG extensions are described here: https://www.trustedcomputinggroup.org/specs/PCClient/TCG_PCClientImplementationforBIOS_1-20_1-00.pdf I have tried to keep the patching with rombios.c to a minimum, but...

Hi Lists, I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu when starting an instance, as without that, it will only use one thread and hence of limited/no use. The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to qemu, which is a different parameter, that conflicts with the other one. Can we discuss, if...

NB: This requires a qemu patch by Eduardo which is currently awaiting review: https://www.mail-archive.com/qemu-devel@nongnu.org/msg422959.html So not to be applied yet unless that qemu change goes upstream. Rich.

On 25/09/09 18:05, Tilmann Scheller wrote: > Hi Andrew, > > On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery<andrew at aj.id.au> wrote: >> TCG seperates the guest (ARM) code into blocks - my front end translates >> these to LLVM IR for LLVM to translate to x86. The assumption is that LLVM >> will produce a better translation than TCG*. At some future point the >> TCG-generated native block is replaced by the LLVM's,...

...er wrote: > >>>>>> Hi Lists, > >>>>>> > >>>>>> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. > >>>>>> > >>>>>> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu > >>>>>> when starting an instance, as without that, it will only use one thread > >>>>>> and hence of limited/no use. > >>>>>> > >>>>>> The problem is, that libvirt itself, passes...

On Wed, Sep 17, 2014 at 07:59:03PM +0530, Priyanka Ranjan wrote: > libguestfs: command: run: /usr/libexec/qemu-kvm > libguestfs: command: run: \ -nographic > libguestfs: command: run: \ -machine accel=kvm:tcg > libguestfs: command: run: \ -device ? > libguestfs: error: /usr/libexec/qemu-kvm exited with error status 1, see > debug messages above > libguestfs: trace: launch = -1 (error) It looks as if qemu is broken on your machine. What's the output of: /usr/libexec/qemu-kvm -nograph...

...nd it works, but seems like changing the hv should work in a more clean way. any advice is appreciated! The error from the pastebin is: [00038ms] /usr/local/bin/qemu-system-arm \ -global virtio-blk-pci.scsi=off \ -enable-fips \ -nodefaults \ -display none \ -machine accel=kvm:tcg \ -m 500 \ -no-reboot \ -rtc driftfix=slew \ -global kvm-pit.lost_tick_policy=discard \ -kernel /var/tmp/.guestfs-0/appliance.d/kernel \ -initrd /var/tmp/.guestfs-0/appliance.d/initrd \ -drive file=/opt/kore_dtf/dropthefw/build_directory/5/rootfs.raw,cache=writeback,id=h...

Hi all, If it's not the right place to ask, please forgive me. Currently I'm working on a new operating system concept, called "Om". The first feature would be Android-like apps, coming in *.opk files that would contain all needed resources and source-code expressed in LLVM-IR assembly language. http://sett.com/openminded-os/uid/88508 How does it sound ? Julien

Hello > Again, from what I understand, llvm-qemu worked by emitting LLVM IR from > QEMU IR API calls. This project goes straight from ARM to LLVM IR, bypassing > QEMU's IR, (partially) in the hope that more information about the original > intent of the code is retained. Ok, what's left from QEMU then? :) > generating reasonable code - this approach keeps it in place while

On 05.02.20 10:49, Wang, Wei W wrote: > On Wednesday, February 5, 2020 5:37 PM, David Hildenbrand wrote: >>> >>> Not sure how TCG tracks the dirty bits. But In whatever >>> implementation, the hypervisor should have >> >> There is only a single bitmap for that purpose. (well, the one where KVM >> syncs to) >> >>> already dealt with the race between he current round and the previous &g...

On 05.02.20 10:49, Wang, Wei W wrote: > On Wednesday, February 5, 2020 5:37 PM, David Hildenbrand wrote: >>> >>> Not sure how TCG tracks the dirty bits. But In whatever >>> implementation, the hypervisor should have >> >> There is only a single bitmap for that purpose. (well, the one where KVM >> syncs to) >> >>> already dealt with the race between he current round and the previous &g...

...e point of llvm-qemu project was that you don't need to > go with all that hacks and workarounds The point of this is to provide an alternative backend to QEMU that can be run in a separate thread to generate optimised blocks, while working as transparently as possible. A nice property of TCG (QEMU's current JIT, which was dyngen when llvm-qemu was written) is that it's extremely fast at generating reasonable code - this approach keeps it in place while we do extra, possibly more expensive work out of sight. It might not be a pretty idea, but LLVM does generate some very tig...

...dhat.com> wrote: > > On Thu, Aug 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: > >> Hi Lists, > >> > >> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. > >> > >> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu > >> when starting an instance, as without that, it will only use one thread > >> and hence of limited/no use. > >> > >> The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to > >> qemu, which is a diff...

...g 20, 2020 at 08:11:30PM +0200, Jan Walzer wrote: > >>>> Hi Lists, > >>>> > >>>> I currently have the issue of wanting to use emu-system-x86_64 on a ppc64le platform. > >>>> > >>>> It is imperative to pass the "-accel tcg,thread=multi” parameter to qemu > >>>> when starting an instance, as without that, it will only use one thread > >>>> and hence of limited/no use. > >>>> > >>>> The problem is, that libvirt itself, passes “-machine q35,accel=tcg” to &gt...