Specify the number of CPUs that can run on ZynqMP.
Signed-off-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daud
---
V2:
- Use macros
hw/arm/xlnx-zcu102.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
index 519a16ed98..e2d15a1c9d 100644
-
On 28.10.2017 00:54, Paolo Bonzini wrote:
> On 26/10/2017 21:03, Philippe Mathieu-Daudé wrote:
>>> AFAIK the only target that is so far supposed to work with
>>> --disable-tcg is i386. The configure script however lets you try to
>>> build without TCG if the host has an alternative accelerator (e.g
On 28/10/2017 08:57, Alexey Kardashevskiy wrote:
> On 27/10/17 18:12, Jeff Cody wrote:
>> VHDX does not support migration (VMDK fails the same way).
>
> Probably a very ignorant question but how can an image format not support
> migration at all? Is not it simple writing blocks, one-by-one? Thank
On 26 October 2017 at 23:59, Stefano Stabellini wrote:
> The following changes since commit 325a084c1ebccb265a3c8f1dd092ffbbfb448a00:
>
> Merge remote-tracking branch
> 'remotes/stefanberger/tags/pull-tpm-2017-10-24-1' into staging (2017-10-26
> 09:20:11 +0100)
>
> are available in the git rep
Launchpad has imported 15 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=979411.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://hel
I think this might have been fixed with this commit here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0ca4f94195cce77b624ed
Or can you still reproduce it with the current version of QEMU?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you a
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Upstream here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e2462113b2003085ad16f15e1
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1338957
QEMU nowadays seems to report "Check failed: Cannot allocate memory" ...
so I assume that is OK and we can now close this bug?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Fix had been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e9d21c436f716603b3
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/131
Triaging old bug tickets ... How did you start QEMU here? Can you still
reproduce this issue with the latest version of QEMU?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https:
** Changed in: qemu
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1296882
Title:
add next free device option to qemu-img
Status in QEMU:
New
Bug description
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
** Project changed: qemu => qemu (Ubuntu)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1288259
Title:
KVM vms are paused and cannot be deleted due to hardware error 0x0
Status in qemu package in
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU and OpenBSD? Or could we close this ticket
nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is sub
Patch seems to have been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4b9430294ed406a00f045d
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launch
I'm not sure if this can still be reproduces but I've found a workaround
quite a while ago. The problem disappeared once I migrated the virtual
machines using 32 bit OS images to 64 bit. The mix of 32 and 64 bit VMs
was the causing these problems at least on my server.
--
You received this bug no
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
Since there hasn't been a reply within the last 5 months, I assume this
has been fixed and thus close now this ticket accordingly.
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed t
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
I assume Stefan's fix had been included (likely
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=736ec1677f1ae7e64f2f ?),
so I'm closing this ticket now. But if you still can reproduce this
issue, please let us know.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug
Good question. Over time I've got some feedback that the whole config
file mechanism is really just a second class citizen anyway. I'm happy
for now (running 2.7) and don't really care too much.
Nevertheless: I'd be absolutely excited if I could reliably configure
(and have nice documentation that
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays? Did you
report it to the libusb folks?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bug
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1247478
Title:
usb passthrough mass storage write data corruption
Status in QEMU:
Incomplete
B
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QE
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
Triaging old bug tickets... can you still reproduce this issue with the
latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
Last time I saw this error in my mcelog was in August. Probably, some
update fixed it. I'll check the next days/weeks if I still see it. This
is a quite long time, at the time of my original bug report, I got the
errors multiple times a day and later multiple times a week.
About the workaround mov
I'll send a patch only when there is a clear real use case.
Thanks for your reply.
On Mon, Oct 23, 2017 at 11:30 PM, Keith Busch wrote:
> On Sat, Oct 21, 2017 at 03:54:16PM +0900, Minwoo Im wrote:
>> Add support HMB(Host Memory Block) with feature commands(Get Feature, Set
>> Feature).
>> nvme-4
On Tue, Oct 24, 2017 at 1:18 AM, Stefan Hajnoczi wrote:
> On Sat, Oct 21, 2017 at 03:54:16PM +0900, Minwoo Im wrote:
>> Add support HMB(Host Memory Block) with feature commands(Get Feature, Set
>> Feature).
>> nvme-4.14 tree supports HMB features.
>> This patch will make nvme controller to return
I still reproduce this with QEMU v2.10.0-1649-ga93ece4.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1338591
Title:
Cursor jumps on shape change with vmware vga
Status in QEMU:
Incomplete
Bug
Since this bug report was filed OpenBSD has switched from 32-bit time_t
to 64-bit time_t on all archs (yes, including 32-bit archs like i386,
arm, powerpc). So instead of INT_MAX TIME_MAX should now be set to
LLONG_MAX.
--
You received this bug notification because you are a member of qemu-
devel
Public bug reported:
I have a Win 10 Pro x64 guest inside a qemu/kvm running on an Arch x86_64 host.
The VM has a physical GPU passed through, as well as the physical USB
controllers, as well as a dedicated SSD attached via SATA; you can find the
complete libvirt xml here: https://pastebin.com/
** Changed in: qemu
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1338591
Title:
Cursor jumps on shape change with vmware vga
Status in QEMU:
Triaged
Bug de
** Changed in: qemu
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/902720
Title:
TIME_MAX not set correctly for OpenBSD in qemu-common.h
Status in QEMU:
Triag
On 14.09.2017 15:52, Peter Maydell wrote:
> On 11 September 2017 at 18:16, Kamil Rytarowski wrote:
>> openpty(3) might:
>> - exists in libc (OSX)
>> - exists in libutil (GNU, BSD)
>> - does not exist (SmartOS)
>>
>> Add a function to discover this function in the ./configure script.
>> Add new
On 10.10.2017 16:16, Paolo Bonzini wrote:
On 27/09/2017 21:31, Gerhard Wiesinger wrote:
On 15.09.2017 19:07, Paolo Bonzini wrote:
On 15/09/2017 16:43, Gerhard Wiesinger wrote:
On 27.08.2017 20:55, Paolo Bonzini wrote:
Il 27 ago 2017 4:48 PM, "Gerhard Wiesinger" mailto:li...@wiesinger.com>> ha
NetBSD 8.0(beta) ships with KERN_PROC_PATHNAME in sysctl(2).
Older NetBSD versions can use argv[0] parsing fallback.
This code section is partly shared with FreeBSD.
Signed-off-by: Kamil Rytarowski
---
util/oslib-posix.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --
On Sat, Oct 28, 2017 at 12:53:50PM +1100, Alexey Kardashevskiy wrote:
> On 28/10/17 00:14, Daniel P. Berrange wrote:
> > Some users can't run a bare 'git' command, due to need for a transparent
> > proxying solution such as 'tsocks'. This adds an argument to configure to
> > let users specify such
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table
Public bug reported:
Building a reduced test program with 'gcc -O2 -fno-inline -mcpu=power8'
produces wrong results at runtime. I don't think gcc is at fault here.
---
#include
int getWord(const float x)
{
return *(int*)&x;
}
void main()
{
int foo = getWord(+123.456f);
int bar = getW
I am running:
qemu-ppc64le-static -L /usr/powerpc64le-linux-gnu ./a.out
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1728325
Title:
POWER8: Wrong behaviour with float-to-int punning
Status in QE
On 29/10/17 07:45, Daniel P. Berrange wrote:
> On Sat, Oct 28, 2017 at 12:53:50PM +1100, Alexey Kardashevskiy wrote:
>> On 28/10/17 00:14, Daniel P. Berrange wrote:
>>> Some users can't run a bare 'git' command, due to need for a transparent
>>> proxying solution such as 'tsocks'. This adds an argu
On 27.10.17 18:14, Collin L. Walling wrote:
> The sclp console in the s390 bios writes raw data,
> leading console emulators (such as virsh console) to
> treat a new line ('\n') as just a new line instead
> of as a Unix line feed. Because of this, output
> appears in a "stair case" pattern.
>
>
Implemented system reset by creating SYSRESETREQ gpio
out from nvic.
Signed-off-by: Subbaraya Sundeep
---
hw/arm/msf2-soc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/arm/msf2-soc.c b/hw/arm/msf2-soc.c
index 6f97fa9..a8ec2cd 100644
--- a/hw/arm/msf2-soc.c
+++ b/hw/arm/ms
51 matches
Mail list logo
