Public bug reported:
hello!
execute "qemu-system-x86_64 -M pc -m 256 -hda pc/img.qcow2 -nographic -net
nic,vlan=0,macaddr=00:e0:fc:00:00:01 -net tap,vlan=0,ifname=tap0,script=no
-serial tcp::,server,nowait -boot c"
and then
(qemu) pci_add auto nic vlan=1,macaddr=00:e0:fc:40:20:02
Property 'e
On Wed, Jun 26, 2013 at 01:56:33PM +0200, Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Fri, 14 Jun 2013 13:46:41 +0800
> > Amos Kong wrote:
> >
> >> On Fri, May 31, 2013 at 08:31:17PM +0800, Amos Kong wrote:
> >> > On Thu, May 30, 2013 at 11:48:46AM -0500, Anthony Liguori wrote:
>
On 07/01/13 20:54, Seiji Aguchi wrote:
> [Issue]
> When we offer a customer support service and a problem happens
> in a customer's system, we try to understand the problem by
> comparing what the customer reports with message logs of the
> customer's system.
>
> In this case, we often need to kno
Il 02/07/2013 01:31, Andreas Färber ha scritto:
>> > Signed-off-by: Paolo Bonzini
> Needs an update after ppc-next merge, cf. attached.
Thanks!
Paolo
Il 01/07/2013 20:33, Jan Kiszka ha scritto:
> On 2013-06-28 18:58, Paolo Bonzini wrote:
>> Add ref/unref calls at the following places:
>>
>> - places where memory regions are stashed by a listener and
>> used outside the BQL (including in Xen or KVM).
>>
>> - memory_region_find callsites
>
> Yo
On 07/01/13 19:59, Tomoki Sekiyama wrote:
> On 7/1/13 9:29 , "Laszlo Ersek" wrote:
>
>>> +error:
>>> +qmp_guest_fsfreeze_thaw(NULL);
>>
>> Passing NULL here as "errp" concerns me slightly. I've been assuming
>> that "errp" is never NULL due to the outermost QMP layer always wanting
>> to rece
On Wed, Jun 26, 2013 at 11:54:20AM +0200, Markus Armbruster wrote:
> Amos Kong writes:
>
> > We want to implement mac programming over macvtap through Libvirt,
> > related rx-filter configuration contains main mac, some of rx-mode
> > and mac-table.
> >
> > The previous patch adds QMP event to no
Assign source image as the backing hd of target bs, so reading target bs
gets the point-in-time copy of data from source image.
Signed-off-by: Fam Zheng
---
block/backup.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/block/backup.c b/block/backup.c
index 4e9f927..2dd0540 10
Signed-off-by: Fam Zheng
---
block.c | 71 ++---
1 file changed, 11 insertions(+), 60 deletions(-)
diff --git a/block.c b/block.c
index d1ce570..ae5de17 100644
--- a/block.c
+++ b/block.c
@@ -2015,12 +2015,6 @@ BlockDriverState *bdrv_fi
Add target-id (optional) to drive-backup command, to make the target bs
a named drive so that we can operate on it (e.g. export with NBD).
Signed-off-by: Fam Zheng
---
blockdev.c | 4 +++-
qapi-schema.json | 7 +--
qmp-commands.hx | 3 ++-
3 files changed, 10 insertions(+), 4 deletion
The patch only does a rename: bdrv_in_use is obsecure literally (any BDS
is certain to be used somewhere). Rename it to bdrv_is_shared since we
have reference count now and the user number of the BDS is reflected
there.
Signed-off-by: Fam Zheng
---
block.c | 16 ++--
bl
Previously, nbd call drive_get_ref on the drive of bs. A BDS doesn't
always have associated dinfo, it's more proper to use bdrv_get_ref().
Signed-off-by: Fam Zheng
---
blockdev-nbd.c | 9 +
nbd.c | 5 +
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/blockdev-
Device attach, NBD server and block job can share a BlockDriverState,
this patch makes them to use refcount to grab/release a bs so they don't
interfere each other with BDS lifecycle.
Local BDS allocation/releasing don't need to use refcount to manage it,
just use bdrv_new() and bdrv_delete().
If
This series adds for point-in-time snapshot NBD exporting based on
drive-backup. The ideas is described below and patches followed (the missing
part is item 3, which work is in progress by Ian Main who will have another
patch on it). As the work does not overlap, these series should be quite
review
Use numeric value to replace in_use flag in BDS, this will make
lifecycle management with ref count possible. This patch only replaces
existing uses of bdrv_set_in_use, so no logic change here.
Signed-off-by: Fam Zheng
---
block-migration.c | 4 ++--
block.c
Il 02/07/2013 01:42, Andreas Färber ha scritto:
> I happened to notice that the scripted approach you describe in the
> cover letter causes some unnecessary indirection here:
> In this hunk a human could've just supplied the function argument obj.
> But since OBJECT() is not a dynamic cast and f is
Adding Libvirt list.
Thanks,
Shastri
Original Message
Subject:Biweekly upstream qemu-kvm test report - July 1st, 2013
Date: Mon, 01 Jul 2013 19:45:32 +0530
From: chandrashekar shastri
To: qemu-devel@nongnu.org, ltc-...@lists.linux.ibm.com,
virt-test-de...@redhat
Hi,
Can QEMU support wayland? I'd like to know if anybody have ideas/solutions on
that.
Thanks,
Max
On 07/02/2013 10:21 AM, Alexander Graf wrote:
>
> On 02.07.2013, at 02:06, David Gibson wrote:
>
>> On Thu, Jun 27, 2013 at 10:17:19PM +1000, Alexey Kardashevskiy wrote:
>>> On 06/27/2013 09:47 PM, David Gibson wrote:
On Thu, Jun 27, 2013 at 04:45:45PM +1000, Alexey Kardashevskiy wrote:
Am 29.06.2013 22:01, schrieb Andreas Färber:
> diff --git a/target-microblaze/helper.c b/target-microblaze/helper.c
> index 01d4bbf..86aad6a 100644
> --- a/target-microblaze/helper.c
> +++ b/target-microblaze/helper.c
> @@ -152,7 +152,7 @@ void mb_cpu_do_interrupt(CPUState *cs)
>
Am 26.06.2013 19:35, schrieb Andreas Färber:
> Hello,
>
> This series changes cpu_single_env, first_cpu, next_cpu and thread_env to
> CPUState.
>
> v3 defers the removal of qemu_for_each_cpu() and drops CPU_INTERRUPT_*
> changes,
> renames cpu_single_cpu to current_cpu, while enforcing consiste
On 02.07.2013, at 02:06, David Gibson wrote:
> On Thu, Jun 27, 2013 at 10:17:19PM +1000, Alexey Kardashevskiy wrote:
>> On 06/27/2013 09:47 PM, David Gibson wrote:
>>> On Thu, Jun 27, 2013 at 04:45:45PM +1000, Alexey Kardashevskiy wrote:
Currently XICS interrupt controller is not a QEMU devi
On Thu, Jun 27, 2013 at 10:17:19PM +1000, Alexey Kardashevskiy wrote:
> On 06/27/2013 09:47 PM, David Gibson wrote:
> > On Thu, Jun 27, 2013 at 04:45:45PM +1000, Alexey Kardashevskiy wrote:
> >> Currently XICS interrupt controller is not a QEMU device. As we are going
> >> to support in-kernel emul
Hi,
Am 02.07.2013 00:24, schrieb jinho hwang:
> Thank you for your reply. I tried qemu-1.5.0 with --enable-kvm, but
> there is still a big difference between qemu-kvm-1.2.0 and qemu-1.5.0.
> They both use the same command line to create VM. Am I missing something
> in the command-line?
>
> sudo q
Am 25.06.2013 16:15, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini
> ---
> hw/usb/hcd-ehci-sysbus.c | 2 +-
> hw/usb/hcd-ehci.c | 8
> hw/usb/hcd-ohci.c | 3 ++-
> hw/usb/hcd-uhci.c | 4 +++-
> hw/usb/hcd-xhci.c | 12 ++--
> hw/vi
Am 25.06.2013 16:15, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini
Needs an update after ppc-next merge, cf. attached.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
diff --cc hw/ppc/mp
Am 25.06.2013 16:14, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini
Needs update after ppc-next merge, cf. attached.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
diff --cc hw/intc/open
Am 02.07.2013 01:16, schrieb Andreas Färber:
> Am 28.06.2013 18:58, schrieb Paolo Bonzini:
>> Signed-off-by: Paolo Bonzini
>
> Since the ppc-next merge, something like the attached is necessary for
> iommu-for-anythony branch to apply to master.
Add to that the ppc KVM-only:
diff --git a/hw/int
Am 28.06.2013 18:58, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini
Since the ppc-next merge, something like the attached is necessary for
iommu-for-anythony branch to apply to master.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Gu
Hi Paolo,
Thank you for your reply. I tried qemu-1.5.0 with --enable-kvm, but there
is still a big difference between qemu-kvm-1.2.0 and qemu-1.5.0. They both
use the same command line to create VM. Am I missing something in the
command-line?
sudo qemu-system-x86_64 -name vm -m 1g -hda /home/jinh
Public bug reported:
Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit
Host: Windows 7 64-bit
Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3
ppc64, Fedora 18 ppc64
libiconv: 1.14
glib: 2.28.8
gettext: 0.18.1.1
pixman: 0.30.0
Il 01/07/2013 23:51, jinho hwang ha scritto:
> Hi Guys,
>
> I am new to kvm development (used to work on Xen). I used qemu-kvm-1.2.0
> first, and then due to pci memory size (x64 bit support), I switched
> from 1.2.0 to qemu-kvm-1.5.0 (same for 1.3.0~).
There is no qemu-kvm 1.5.0. You are using
Hi Guys,
I am new to kvm development (used to work on Xen). I used qemu-kvm-1.2.0
first, and then due to pci memory size (x64 bit support), I switched from
1.2.0 to qemu-kvm-1.5.0 (same for 1.3.0~). After that, my VM slows down
significantly including booting and execution. Also, sometimes kernel
Am 01.07.2013 20:03, schrieb Richard Henderson:
> On 07/01/2013 10:51 AM, Andreas Färber wrote:
>> I wonder, all targets seem to implement the same pattern of passing a
>> hard-coded bool argument to their internal function.
>>
>> Is there any reason not to have translate-all.c call the function wi
Am 01.07.2013 um 22:20 schrieb Paolo Bonzini :
> Il 27/06/2013 15:11, Peter Lieven ha scritto:
>> if the device supports unmapping and unmapped blocks read as
>> zero ensure that the whole device is unmapped and report
>> .has_zero_init = 1 in this case to speed up qemu-img convert.
>
> This can
On 1 July 2013 21:52, Paolo Bonzini wrote:
> Il 01/07/2013 18:26, Peter Maydell ha scritto:
>> Since the two largest cases are both "cpu_single_env must be TLS"
>> (ie (a) system emulation built with KVM support and (b) linux-user),
>> the set of targets which can be non-TLS is really really small
Il 27/06/2013 15:11, Peter Lieven ha scritto:
> if the device supports unmapping and unmapped blocks read as
> zero ensure that the whole device is unmapped and report
> .has_zero_init = 1 in this case to speed up qemu-img convert.
This can still take several minutes. Do you need any special time
Am 01.07.2013 22:19, schrieb Richard Henderson:
> Prepare for removing env from DisasContext.
>
> Signed-off-by: Richard Henderson
> ---
> target-alpha/translate.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/target-alpha/translate.c b/target-alpha/translate
Il 01/07/2013 18:26, Peter Maydell ha scritto:
> > I think we should strive for one of these two:
> >
> > (1) all targets are TLS;
> >
> > (2) all targets are non-TLS if this is possible.
> >
> > Either maximizes the homogeneity across platforms.
>
> Since the two largest cases are both "cpu_singl
Public bug reported:
Hi,
Tried to establish virtual serial connection between two Windows Guest
VMs(Windows 2008 Server).
As it mentioned under the link,
http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging
Started VM using the below command with serial device as TCP port.
#
On 06/21/2013 07:20 AM, Bas van Sisseren wrote:
> The slirp dhcp-server normally returns its own address as tftp
> nextserver for netbooting. This patch makes that address
> configurable, so it is possible to use an external tftp boot-
> environment.
>
> Signed-off-by: Bas van Sisseren
> ---
> n
Il 01/07/2013 20:33, Jan Kiszka ha scritto:
> > This function is not used outside the iothread mutex, so it
> > can use ram_list.mru_block.
>
> Add a comment to qemu_ram_addr_from_host to document this requirement?
Right now there is hardly any documentation of what does _not_ require
the iothrea
Hi,
The developer of WinUAE has been adding support for Cirrus-based graphics
cards to the program, based on the Qemu Cirrus emulation. Apparently he
has discovered some bugs, which I thought I'd post about here in case
someone who knows about that code wants to take a look.
[begin quote]
Graphi
Public bug reported:
Hi,
To setup a virtual serial connections between two Windows 2008 R2(64-bit) guest
VMs, I am referring the link
http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging
I started the host VM using the command
# /usr/local/bin/qemu-system-x86_64 -smp 1 -enab
Hi all,
When use nahanni device as following, The QEMU/KVM doesn’t work.
I attach two ivshmem devices to VM, QEMU/KVM only supports a ivshmem device,
why?
Expect your reply!
-device
virtio-net-pci,vlan=0,id=net0,mac=DE:AD:BE:09:03:01,bus=pci.0,addr=0x5 \
-net tap,script=/etc/qem
Il 01/07/2013 20:34, Jan Kiszka ha scritto:
> The transformation looks correct, but I'm currently not understanding in
> which cases we still need the loop. address_space_translate should
> return as much of the target mr as the region can contiguously provide, no?
You could have separate sections
On 07/01/2013 12:25 PM, Peter Maydell wrote:
> Does any OS have a __thread which compiles but is broken, or can
> we just have a configure test for this? That would let MacOSX+clang
> use __thread.
I suspect that this will work. Some targets may succeed in using gcc's
"emutls" path, which while s
On 07/01/2013 10:21 AM, Andreas Färber wrote:
> Thanks. If Blue or you don't have any further comments on the previous
> part 10 series v3, I will queue that on qom-cpu (rebasing right now).
Nothing further from me.
r~
On 07/01/2013 12:41 PM, Peter Maydell wrote:
> Returning to the point, what we're after here is "a type which will hold
> a guest virtual address but whose size doesn't depend on the target the
> way target_ulong does", right? My inclination is to suggest that we have
> a 'vaddr' typedef by analogy
Which allows removing env from DisasContext.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index b59f919..7dac0c8 100644
--- a/target-alpha/translat
Prepare for removing env from DisasContext.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 4db16db..b59f919 100644
--- a/target-alpha/translate.c
As discussed in the QOM thread.
r~
Richard Henderson (2):
target-alpha: Copy singlestep_enabled to DisasContext
target-alpha: Copy implver to DisasContext
target-alpha/translate.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
--
1.8.1.4
On 1 July 2013 15:25, Peter Maydell wrote:
> Does any OS have a __thread which compiles but is broken, or can
> we just have a configure test for this? That would let MacOSX+clang
> use __thread.
I believe this was recently the case on NetBSD - code with __thread
would build, but fail at run time
At the time we started working on AArch64, we were not certain that our
implementation would be published in near future. Now that this is
cleared up we are more than happy to coordinate together.
On 28 June 2013 14:04, Andreas Färber wrote:
I had been looking into that tree myself, and apart
On 1 July 2013 20:03, Richard Henderson wrote:
> I would think hwaddr wouldn't be appropriate, since that's supposed to be
> talking about physical addresses, and that's not the case here. The name (and
> admittedly minimal documentation for) ram_addr_t sounds right, but it seems to
> be sized wr
On 1 July 2013 19:52, Ed Maste wrote:
> The most recent version of this patch posted by Paolo that I see has:
>
> +#if defined(__linux__) || defined(__FreeBSD__)
> +#define DECLARE_TLS(type, x) \
>
> while this one has only __linux__. Do you mind picking up that
> change, if t
On 1 July 2013 20:22, Peter Maydell wrote:
In particular this would try to build
> a 64 bit binary but with QEMU's copy of the 32 bit kernel headers:
> I'm not sure that's expected (by the kernel folk) to work at all. If not,
> we should just not put the line into configure in the first place.
S
On 1 July 2013 19:46, Alexander Spyridakis
wrote:
> On 29 June 2013 21:20, Peter Maydell wrote:
>> So this is enabling support for emulating 32 bit VMs with a
>> QEMU running as a 64 bit process, but the commit message
>> doesn't mention this. Did you test that combination?
Actually I wasn't qui
On 1 July 2013 19:06, Alexander Spyridakis
wrote:
> On 29 June 2013 21:21, Peter Maydell wrote:
>> So, which documentation or TRM or hardware are you basing this
>> definition of an A57 Versatile Express daughterboard on?
>
> Currently there is no existing hardware that I am aware of, or a
> publ
On 1 July 2013 18:34, Peter Maydell wrote:
> This patchset is v5 of the "preparation patchset" that started
> off with Alex, was passed to John Rigby and now to me.
Also available via git:
git://git.linaro.org/people/pmaydell/qemu-arm.git aarch64
(caution: branch likely to rebase in future)
--
On 07/01/2013 10:25 AM, Andreas Färber wrote:
> This is the first case where I am proposing the use of uint64_t in place
> of target_ulong. In this case a gdb command using such a hook is not
> performance-sensitive. Do you see this as an acceptable path for adding
> further CPUClass hooks such as
> > > void error_report(const char *fmt, ...)
> > > {
> > > va_list ap;
> > > +char timestr[TIMESTAMP_LEN];
> > > +
> > > +if (enable_timestamp_msg) {
> > > +qemu_get_timestamp_str(×tr);
> > > +error_printf("%s ", timestr);
> > > +}
> > >
> > > error_print_lo
On 2013-06-28 18:58, Paolo Bonzini wrote:
> First of all, rename "todo" to "done".
>
> Second, clearly separate the case of done == 0 from the case of done != 0.
> This will help handling reference counting in the next patch.
>
> Third, this test:
>
> if (memory_region_get_ram_addr(
On 6/30/13 9:16 , "Gal Hammer" wrote:
>On 26/06/2013 01:31, Tomoki Sekiyama wrote:
>
>>> Also, is it needed to call VSSCheckOSVersion from the requestor? I
>>> would think that checking VSSAPI.DLL is stronger than checking the
>>> version, and indeed you do that check too.
>>
>> In Windows XP, V
[Issue]
When we offer a customer support service and a problem happens
in a customer's system, we try to understand the problem by
comparing what the customer reports with message logs of the
customer's system.
In this case, we often need to know when the problem happens.
But, currently, there is
On 1 July 2013 05:35, Stefan Hajnoczi wrote:
> From: Paolo Bonzini
>
> Fast TLS is not available on some platforms, but it is always nice to
> use it. This wrapper implementation falls back to pthread_get/setspecific
> on POSIX systems that lack __thread, but uses the dynamic linker's TLS
> sup
On 29 June 2013 21:20, Peter Maydell wrote:
> So this is enabling support for emulating 32 bit VMs with a
> QEMU running as a 64 bit process, but the commit message
> doesn't mention this. Did you test that combination?
Nope, this case is not handled. Currently it won't crash but of course
won't
On 2013-06-28 18:58, Paolo Bonzini wrote:
> The iothread mutex might be released between map and unmap, so the
> mapped region might disappear.
>
> Signed-off-by: Paolo Bonzini
> ---
> exec.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/exec.c b/exec.
On 2013-06-28 18:58, Paolo Bonzini wrote:
> This function is not used outside the iothread mutex, so it
> can use ram_list.mru_block.
Add a comment to qemu_ram_addr_from_host to document this requirement?
>
> Signed-off-by: Paolo Bonzini
> ---
> exec.c | 12 ++--
> 1 file changed, 10 i
On 2013-06-28 18:58, Paolo Bonzini wrote:
> It will be needed in the next patches.
>
> Signed-off-by: Paolo Bonzini
> ---
> cputlb.c | 2 +-
> exec.c| 33 -
> include/exec/cpu-common.h | 2 +-
> target-i386/kvm.c | 4
On 2013-06-28 18:58, Paolo Bonzini wrote:
> After the next patch it would not be used elsewhere anyway. Also,
> the _nofail and the standard versions of this function return different
> things, which is confusing. Removing the function from the public headers
> limits the confusion.
>
> Signed-o
On 2013-06-28 18:58, Paolo Bonzini wrote:
> Add ref/unref calls at the following places:
>
> - places where memory regions are stashed by a listener and
> used outside the BQL (including in Xen or KVM).
>
> - memory_region_find callsites
You missed some recently added ones. Check hw/acpi/piix4
From: Alexander Graf
Some syscall handlers have special code for ARM enabled that we don't
need on AArch64. Exclude AArch64 in those cases. In other places we
can share struct definitions with other targets or have to provide our
own.
With this patch applied, most syscall definitions in linux-us
On 29 June 2013 21:24, Peter Maydell wrote:
> On 28 June 2013 13:11, Mian M. Hamayun
> wrote:
>> From: Alexander Spyridakis
>>
>> AArch64 uses a cpu-release-addr memory location (defined in the dts) as
>> a way to inform secondary CPUs where to jump to and enter their holding
>> pen. Inject a v
On 29 June 2013 21:21, Peter Maydell wrote:
> On 28 June 2013 13:11, Mian M. Hamayun
> wrote:
> > From: "Mian M. Hamayun"
> >
> > The vexpress model for A57 is based on the A15 machine model with a few
> > changes in the daughterboard initialization (using a subset of A15
> > functionality). Th
From: Alexander Graf
Add the necessary code to configure to handle AArch64 as a target
CPU (we already have some code for supporting it as host). Note
that this doesn't enable the AArch64 targets yet.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
Message-id: 1368505980-17151-12-git-s
From: Alexander Graf
We will need to share the disassembly status struct between AArch32 and
AArch64 modes. So put it into a header file that both sides can use.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
Message-id: 1368505980-17151-2-git-send-email-john.ri...@linaro.org
Signed-o
On 07/01/2013 10:51 AM, Andreas Färber wrote:
> I wonder, all targets seem to implement the same pattern of passing a
> hard-coded bool argument to their internal function.
>
> Is there any reason not to have translate-all.c call the function with
> that true/false directly?
The idea is to avoid
On 06/29/2013 01:01 PM, Andreas Färber wrote:
> Replace GET_REG*() macros by gdb_get_reg*() inline functions for
> clarity and drop breaks after return.
>
> Allows to move target-specific code to new target-*/gdbstub.c files.
>
> Signed-off-by: Andreas Färber
This one's quite hard to read.
I w
On 29 June 2013 21:17, Peter Maydell wrote:
>
> > +#ifdef TARGET_AARCH64
> > +int kvm_arch_init_vcpu(CPUState *cs)
> > +{
> > +struct kvm_vcpu_init init;
> > +int ret;
> > +
> > +/* Try initializing with Foundation Models */
> > +init.target = KVM_ARM_TARGET_FOUNDATION_V8;
> > +
From: Alexander Graf
Correct a few places that were using uint32_t or a 32 bit
only format string to handle something that should be a target_ulong.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
[PMM: split out to separate patch; added gen_goto_tb() and
gen_set_pc_im() dest params to
From: Alexander Graf
Add the AArch64 termbits.h with all the target's termios related
constants and structures.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
[PMM: split out from another patch]
Signed-off-by: Peter Maydell
---
linux-user/aarch64/termbits.h | 220 ++
On 07/01/2013 07:29 AM, Laszlo Ersek wrote:
> some comments below
>
> On 06/06/13 17:06, Tomoki Sekiyama wrote:
>> Support guest-fsfreeze-freeze and guest-fsfreeze-thaw commands for Windows
>> guests. When fsfreeze command is issued, it calls the VSS requester to
>> freeze filesystems and applicat
On 7/1/13 10:50 , "Laszlo Ersek" wrote:
>On 06/06/13 17:06, Tomoki Sekiyama wrote:
>>+#ifdef HAS_VSS_SDK
>> +if (FAILED(COMRegister())) {
>> +return EXIT_FAILURE;
>> +}
>
>COMRegister() seems to print error messages on failure, OK.
>
>> +#endif
From: Alexander Graf
We should translate AArch64 mode separately from AArch32 mode. In AArch64 mode,
registers look vastly different, instruction encoding is completely different,
basically the system turns into a different machine.
So let's do a simple if() in translate.c to decide whether we c
Am 01.07.2013 19:23, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>> -CPUAlphaState *env;
>> +AlphaCPU *cpu;
>
> Actually, I take this back. I'd prefer that we simply pull out the two
> variables that we need and place them in the DisasContext. That's the wa
On 7/1/13 9:29 , "Laszlo Ersek" wrote:
>>+error:
>> +qmp_guest_fsfreeze_thaw(NULL);
>
>Passing NULL here as "errp" concerns me slightly. I've been assuming
>that "errp" is never NULL due to the outermost QMP layer always wanting
>to receive errors and to serialize them.
>
>Specifically, a NUL
Am 26.06.2013 19:35, schrieb Andreas Färber:
> Move next_cpu from CPU_COMMON to CPUState.
> Move first_cpu variable to qom/cpu.h.
>
> gdbstub needs to use CPUState::env_ptr for now.
> cpu_copy() no longer needs to save and restore cpu_next.
>
> Acked-by: Paolo Bonzini
> [AF: Rebased, simplified
Am 01.07.2013 19:03, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>> if ((env->cr[0] & CR0_PE_MASK)) {
>> +X86CPU *cpu = x86_env_get_cpu(env);
>> static int count;
>>
>> qemu_log("%6d: v=%02x e=%04x i=%d cpl=%d IP=%04x:"
Add a config for aarch64-softmmu; this enables building of this target.
The resulting executable doesn't know about any 64 bit CPUs, but all
the 32 bit CPUs and board models work.
Signed-off-by: Peter Maydell
---
default-configs/aarch64-softmmu.mak | 82 +++
1 f
AArch32 code (ie traditional 32 bit world) expects to be
able to pass a vaddr in a TCGv_i32. However when QEMU is
compiled with TARGET_LONG_BITS=32 the TCG load/store
functions take a TCGv_i64. Abstract out load/store with
a 32 bit vaddr so we have a place to put the zero extension
of the vaddr and
From: Alexander Graf
The AArch64 syscall definitions are all publicly available in the Linux
kernel. Let's add them to our linux-user emulation target, so that we
can easily handle AArch64 syscalls.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
Message-id: 1368505980-17151-8-git-send
Am 01.07.2013 19:16, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>> Also use bool type while at it.
>>
>> Prepares for moving singlestep_enabled field to CPUState.
>>
>> Signed-off-by: Andreas Färber
>> ---
>> target-xtensa/translate.c | 10 ++
>> 1 file cha
From: Alexander Graf
The cpu_env tcg variable will be used by both the AArch32 and AArch64
handling code. Unstaticify it, so that both sides can make use of it.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
Message-id: 1368505980-17151-3-git-send-email-john.ri...@linaro.org
Signed-of
From: Andreas Schwab
This patch adds signal handling for AArch64. The code is based on the
respective source in the Linux kernel.
Signed-off-by: Andreas Schwab
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
Message-id: 1368505980-17151-10-git-send-email-john.ri...@linaro.org
[PMM: fi
On ARM, linux-user emulation includes NWFPE support for emulating the
ancient FPA floating point coprocessor. This has long since been
superseded by VFP and is only required for legacy binaries. The
AArch64 linux-user target doesn't compile in NWFPE support, so make
sure the relevant code is protec
From: Alexander Graf
Glibc 1.17 checks for the host kernel version on startup. Unfortunately,
it also checks whether the host kernel version is recent enough for the
target to run at all.
Since AArch64 support only got introduced in 3.8.0, that means that glibc
refuses to run on any older kernel
Add the main linux-user cpu loop for AArch64. Since AArch64
has a different system call interface, doesn't need to worry
about FPA emulation and may in the future keep the prefetch/data
abort information in different system registers, it's simplest
just to use a completely separate loop from the 32
Richard or anyone,
Am 01.07.2013 19:09, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>> This moves setting the Program Counter from gdbstub into target code.
>> Use uint64_t type as maximum replacement for target_ulong.
>>
>> Signed-off-by: Andreas Färber
>> ---
>>
From: Alexander Graf
We want to be able to debug AArch64 guests. So let's add the respective gdb
stub functions and xml descriptions that allow us to do so.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
Message-id: 1368505980-17151-6-git-send-email-john.ri...@linaro.org
Signed-off-by
1 - 100 of 284 matches
Mail list logo
