Am 20.11.2015 um 07:29 schrieb Qinghao Tang:
> I think the patch can solve this vulnerability.
> I confirm that the loop exist , the poc code can prove that.
>
>
> #include
> #include
> #include
> #include
> #define PAGE_OFFSET 0x0C00
> MODULE_LICENSE("GPL");
> static int hello_init(void)
>
http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg04592.html
shows an example how an endless loop in function action_command can
be achieved.
During my code review, I noticed a 2nd case which can result in an
endless loop.
Reported-by: Qinghao Tang
Signed-off-by: Stefan Weil
---
hw/ne
Hello Qinghao,
+-- On Fri, 20 Nov 2015, Qinghao Tang wrote --+
| I think the patch can solve this vulnerability.
| I confirm that the loop exist , the poc code can prove that.
Great! Thank you so much for the confirmation and the POC code. I'll send an
updated patch shortly.
Thank you.
--
P
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 20, 2015 4:03 AM
>
> > >
> > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > supports modular bus drivers and IOMMU
I think the patch can solve this vulnerability.
I confirm that the loop exist , the poc code can prove that.
#include
#include
#include
#include
#define PAGE_OFFSET 0x0C00
MODULE_LICENSE("GPL");
static int hello_init(void)
{
void* pvirt;
void* pphy;
unsigned long* pdbal;
unsigned
Eric Blake writes:
> On 11/19/2015 01:10 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> [Replace the old commit message with this:]
>>
>> Fixup patch squashed, commit message replaced.
>
> The version of the patch currently on qapi-next (id 22c38fe) missed the
> addition of the new
Paolo Bonzini writes:
> On 19/11/2015 16:29, Markus Armbruster wrote:
>> Commit 29c75dd "json-streamer: limit the maximum recursion depth and
>> maximum token count" attempts to guard against excessive heap usage by
>> limiting total token size (it says "token count", but that's a lie).
>>
>> To
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, November 19, 2015 4:41 PM
>
> Hi,
>
> > > Another area of extension is how to expose a framebuffer to QEMU for
> > > seamless integration into a SPICE/VNC channel. For this I believe we
> > > could use a new region, much like w
Hello Qinghao,
+-- On Fri, 20 Nov 2015, Qinghao Tang wrote --+
| Currently what problem do you have? Perhaps I could provide more support.
Could you please confirm if the proposed patch here fixes the issue.
Secondly there is uncertainty if the CB loop like Jason mentioned earlier is
possi
> From: Song, Jike
> Sent: Friday, November 20, 2015 1:52 PM
>
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On T
On 11/20/2015 12:22 PM, Alex Williamson wrote:
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition
To Jason Wang:
I think this patch should be for qemu-2.5
Thanks
Wen Congyang
On 11/11/2015 02:53 PM, Wen Congyang wrote:
> Signed-off-by: Wen Congyang
> ---
> net/vhost-user.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/vhost-user.c b/net/vhost-user.c
> index
On Fri, 2015-11-20 at 06:16 +0100, Christoph Hellwig wrote:
> Thanks Ming,
>
> from a first quick view this looks great. I'll look over it in a bit
> more detail once I get a bit more time.
Thanks to CC Nic :-)
But funny, I double-checked bash history. I actually CCed Nic.
Don't know why it's l
On Fri, 2015-11-20 at 06:13 +0100, Christoph Hellwig wrote:
> On Thu, Nov 19, 2015 at 04:21:03PM -0800, Ming Lin wrote:
> > #define NVMET_SUBSYS_NAME_LEN 256
> > charsubsys_name[NVMET_SUBSYS_NAME_LEN];
> > +
> > + void*opaque;
> > + void
Thanks Ming,
from a first quick view this looks great. I'll look over it in a bit
more detail once I get a bit more time.
On Thu, Nov 19, 2015 at 04:21:03PM -0800, Ming Lin wrote:
> #define NVMET_SUBSYS_NAME_LEN256
> charsubsys_name[NVMET_SUBSYS_NAME_LEN];
> +
> + void*opaque;
> + void(*start)(void *);
> };
Why can't vhost use
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> > On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> >> On Thu, 19 Nov 2015, Jike Song wrote:
> >>> Hi Alex, thanks for the discussion.
> >>>
> >>> In addition to Kevin's replies, I ha
On Thu, Nov 12, 2015 at 07:45:40PM +0100, BALATON Zoltan wrote:
> >Interesting. Did you use "-usb -device usb-keyboard" to enable usb
> >support in QEMU when running Finnix?
>
> Yes (or more exactly I had a patch always adding usb keyboard instead of
> adb one to match hardware)
Some mac99/pmu9
Hi guys,
After initial discussion at this year's KVM forum, I post the RFC version of
virtio-crypto
device specification now.
If you have any comments, please let me know, thanks.
Regards,
-Gonglei
1 Crypto Device
The virtio crypto device is a virtual crypto device (ie. hardware crypt
1.what is the difference of bdrv_co_readv and bdrv_aio_readv??
2.I am confused about the I/O pocess of qcow2, i find. Can anybody tell me the
detail pocess? or arethere any useful tools to trace the pocess?
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM and Xen?
N
On 11/19/2015 07:09 PM, Paolo Bonzini wrote:
On 19/11/2015 09:40, Gerd Hoffmann wrote:
But this code should be
minor to be maintained in libvirt.
As far I know libvirt only needs to discover those devices. If they
look like sr/iov devices in sysfs this might work without any changes to
libvirt
Currently what problem do you have? Perhaps I could provide more support.
And please give this vulnerability a cve id.
Thanks!
2015-11-04 11:31 GMT+08:00 Jason Wang :
>
>
> On 11/04/2015 02:49 AM, P J P wrote:
> > +-- On Tue, 20 Oct 2015, Jason Wang wrote --+
> > | Can this survive if we had a c
On Thu, Nov 19, 2015 at 10:10:06AM -0500, Matthew Rosato wrote:
> From: Gu Zheng
>
> In order to deal well with the kvm vcpus (which can not be removed without any
> protection), we do not close KVM vcpu fd, just record and mark it as stopped
> into a list, so that we can reuse it for the appendi
>On Thu, Nov 19, 2015 at 12:42:50PM +, Xulei (Stone) wrote:
>> Kevin,
>>
>> After deeply analyzing, i think there may be 3 possible reasons:
>> 1)wrong CountCPUs value. It seems CountCPUs++ in handle_smp() has no
>> lock to protect. So, sometimes, 2 or more vcpu may get the same
>> current
On Mon, 2015-11-16 at 16:16 +1100, David Gibson wrote:
> On Wed, Nov 11, 2015 at 11:27:21AM +1100, Benjamin Herrenschmidt
> wrote:
> > Also use it to clamp the max SMT mode and ensure that the cpu_dt_id
> > are offset by that value in order to preserve consistency with the
> > HW implementations.
>
On Thu, 2015-11-19 at 21:23 +1100, Benjamin Herrenschmidt wrote:
>
> I only just discovered that rfi is actually gone from arch 2.07 :-)
>
> I'll dig a bit more tomorrow.
Ok, so I had a closer look and tore that stuff appart even more :-)
If you are curious, feel free to check out github. I've
From: Ming Lin
This borrows code from Hannes Reinecke's rts-megasas.
Cc: Hannes Reinecke
Signed-off-by: Ming Lin
---
drivers/nvme/target/vhost.c | 108
1 file changed, 108 insertions(+)
diff --git a/drivers/nvme/target/vhost.c b/drivers/nvme/targe
From: Ming Lin
This is used to execute controller specific cmd parse code
Signed-off-by: Ming Lin
---
drivers/nvme/target/admin-cmd.c | 7 +++
drivers/nvme/target/nvmet.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admi
From: Ming Lin
This adds nvme submission/completion queue handlers,
which are ported from qemu-nvme.
And hooks into nvme-target to do the real job.
Cc: Keith Busch
Signed-off-by: Ming Lin
---
drivers/nvme/target/vhost.c | 420 +++-
1 file changed, 416
From: Ming Lin
Signed-off-by: Ming Lin
---
drivers/nvme/target/vhost.c | 102
include/uapi/linux/vhost.h | 17 ++--
2 files changed, 116 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/target/vhost.c b/drivers/nvme/target/vhost.c
index
From: Ming Lin
This is used to execute controller specific start code
Signed-off-by: Ming Lin
---
drivers/nvme/target/core.c | 3 +++
drivers/nvme/target/nvmet.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
index 1bfef66..0a0f
From: Ming Lin
Signed-off-by: Ming Lin
---
drivers/nvme/target/vhost.c | 153
1 file changed, 153 insertions(+)
diff --git a/drivers/nvme/target/vhost.c b/drivers/nvme/target/vhost.c
index 4a147d6..04ed0bc 100644
--- a/drivers/nvme/target/vhost.c
++
From: Ming Lin
Signed-off-by: Ming Lin
---
drivers/nvme/target/vhost.c | 106
1 file changed, 106 insertions(+)
diff --git a/drivers/nvme/target/vhost.c b/drivers/nvme/target/vhost.c
index 01c44b8..4a147d6 100644
--- a/drivers/nvme/target/vhost.c
++
Hi,
This is the first attempt to add a new qemu nvme backend using
in-kernel nvme target.
Most code are ported from qemu-nvme and also borrow code from
Hannes Reinecke's rts-megasas.
It's similar as vhost-scsi, but doesn't use virtio.
The advantage is guest can run unmodified NVMe driver.
So gue
From: Ming Lin
Signed-off-by: Ming Lin
---
drivers/nvme/target/core.c | 1 +
drivers/nvme/target/vhost.c | 264 +++-
include/uapi/linux/vhost.h | 15 +++
3 files changed, 279 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/target/core.c b/dri
From: Ming Lin
Signed-off-by: Ming Lin
---
drivers/nvme/target/Kconfig | 11 +++
drivers/nvme/target/Makefile | 2 ++
drivers/nvme/target/vhost.c | 16
3 files changed, 29 insertions(+)
create mode 100644 drivers/nvme/target/vhost.c
diff --git a/drivers/nvme/target
On Thu, 2015-11-19 at 15:22 +, Eric Auger wrote:
> I am resending this RFC from Oct 12, after kernel 4.4-rc1 and
> QEMU 2.5-rc1, hoping things have calmed down a little bit.
>
> This RFC allows to set up AMD XGBE passthrough. This was tested on AMD
> Seattle.
>
> The first upstreamed device s
On Thu, 2015-11-19 at 13:29 +0300, Pavel Fedin wrote:
> Hello!
>
> > > On some architectures TARGET_PAGE_ALIGN() is not enough to get the right
> > > alignment. For example on ARM TARGET_PAGE_BITS is 10 because some old CPUs
> > > support 1K page size, while minimum SMMU page size is 4K.
> > >
>
On 11/19/2015 01:10 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> [Replace the old commit message with this:]
>
> Fixup patch squashed, commit message replaced.
The version of the patch currently on qapi-next (id 22c38fe) missed the
addition of the new tests/qapi-schema/reserved-enum-q
On 19/11/2015 16:29, Markus Armbruster wrote:
> Commit 29c75dd "json-streamer: limit the maximum recursion depth and
> maximum token count" attempts to guard against excessive heap usage by
> limiting total token size (it says "token count", but that's a lie).
>
> Total token size is a rather im
On 11/19/2015 06:10 AM, Daniel P. Berrange wrote:
> On Thu, Nov 19, 2015 at 01:03:39PM +, Dr. David Alan Gilbert wrote:
>> * Markus Armbruster (arm...@redhat.com) wrote:
>>> "Please keep this list in alphabetical order" has been more honoured
>>> in the breach than in the observance. Clean up.
"Michael S. Tsirkin" writes:
> On Thu, Nov 19, 2015 at 03:38:03PM -0500, Bandan Das wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > From: Bandan Das
>> >
>> > There's no indication of any sort that i440fx doesn't support
>> > "iommu=on"
>>
>> Oh, Markus quite didn't like this approach because
On Thu, Nov 19, 2015 at 03:55:35PM -0500, Bandan Das wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Nov 19, 2015 at 03:38:03PM -0500, Bandan Das wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > From: Bandan Das
> >> >
> >> > There's no indication of any sort that i440fx doesn't suppor
"Michael S. Tsirkin" writes:
> On Thu, Nov 19, 2015 at 03:38:03PM -0500, Bandan Das wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > From: Bandan Das
>> >
>> > There's no indication of any sort that i440fx doesn't support
>> > "iommu=on"
>>
>> Oh, Markus quite didn't like this approach because
On Thu, Nov 19, 2015 at 03:38:03PM -0500, Bandan Das wrote:
> "Michael S. Tsirkin" writes:
>
> > From: Bandan Das
> >
> > There's no indication of any sort that i440fx doesn't support
> > "iommu=on"
>
> Oh, Markus quite didn't like this approach because this is
> true for all other machines too
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* rework loging to match other i.MX drivers
Changes since v2:
* We moved to an inheritance QOM scheme
hw/arm/fsl-imx25.c | 2 +-
hw/misc/Makefile.objs | 1 +
hw/misc/imx25_ccm.c | 243 +
This is to prepare for CCM code refactoring.
This is just a bit of function and enum values renaming.
We also remove some useless intermediate variables.
Signed-off-by: Jean-Christophe Dubois
---
Changes since v1:
* Not present
Changes since v2:
* Not present
hw/misc/imx_ccm.c
The IMX_CCM class is now the base abstract class that is used by EPIT and GPT
timer implementation.
IMX31_CCM class is the concrete class implementing CCM for i.MX31 SOC.
For now the i.MX25 continues to use the i.MX31 CCM implementation.
An i.MX25 specific CCM will be introduced in a later patch
i.MX25 SOC has a different CCM device than i.MX31.
Qemu i.MX25 emulation was built with i.MX31 CCM driver. This allows
Linux to work on top of the i.MX25 emultion but this is not correct.
Furthermore, other SOC we could emulate like i.MX6 have yet a different
implementation of the CCM device.
So
"Michael S. Tsirkin" writes:
> From: Bandan Das
>
> There's no indication of any sort that i440fx doesn't support
> "iommu=on"
Oh, Markus quite didn't like this approach because this is
true for all other machines too. Anyway, I will keep in
mind to take care of this when I post a generic patch
Hi Kevin,
On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, November 19, 2015 2:12 AM
> >
> > [cc +qemu-devel, +paolo, +gerd]
> >
> > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > > Hi all,
> > >
> >
On 13/11/15 13:10, Hervé Poussineau wrote:
> Le 13/11/2015 11:40, Thomas Huth a écrit :
>> On 13/11/15 10:45, Hervé Poussineau wrote:
>>> Le 13/11/2015 05:09, Programmingkid a écrit :
On Nov 12, 2015, at 11:04 PM, qemu-ppc-requ...@nongnu.org wrote:
> Message: 3
> Date: Thu, 1
On 19 November 2015 at 14:35, Andreas Färber wrote:
> Hello Peter,
>
> This is my late QOM (devices) patch queue. Please pull.
>
> v2: GLib version incompatibility addressed, Reviewed-bys added.
>
> Regards,
> Andreas
>
> Cc: Peter Maydell
> Cc: Daniel P. Berrange
> Cc: Pavel Fedin
>
> The foll
Eric Blake writes:
> On 11/19/2015 09:50 AM, Markus Armbruster wrote:
>> Let's think through this on a higher level.
>>
>> I figure the motivation for this patch is twofold:
>>
>> 1. C identifier clash detection
>>
>
>>
>> 2. Dislike for interfaces that differ only in case
>
> And the related
On 19 November 2015 at 13:35, Michael S. Tsirkin wrote:
> The following changes since commit 8337c6cbc37c6b2184f41bab3eaff47d5e68012a:
>
> Update version for v2.5.0-rc0 release (2015-11-13 17:10:36 +)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/virt/kvm/mst
On 11/19/2015 10:03 AM, Peter Maydell wrote:
> On 19 November 2015 at 14:44, Peter Maydell wrote:
>> On 19 November 2015 at 13:21, Peter Maydell wrote:
>>> On 19 November 2015 at 13:12, Peter Maydell
>>> wrote:
Hi. Unfortunately this failed in 'make check' (x86-64 Linux, debug build):
>>
On 11/19/2015 09:50 AM, Markus Armbruster wrote:
> Let's think through this on a higher level.
>
> I figure the motivation for this patch is twofold:
>
> 1. C identifier clash detection
>
>
> 2. Dislike for interfaces that differ only in case
And the related dislike for interfaces that differ
Thanks - marked fixed released for development release. We can SRU this
into trusty if we know exactly which patch actualy fixed it.
** Changed in: qemu (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is s
Eric Blake writes:
> On 11/19/2015 09:12 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> The CpuInfo struct is used only by the 'query-cpus' output
>>> command, so we are free to modify it by adding fields (clients
>>> are already supposed to ignore unknown output fields), or by
>>> c
On 19/11/2015 17:00, Grundmann, Christian wrote:
> Hi, it seems that using virtio-scsi did the trick, But now the VMs
> are pausing without an coredump, so the underlying Problem (no
> storage Error) is not fixed, As I am using Snapshots (and so the
> disks have to grow very fast) I try if tuning
Eric Blake writes:
> On 11/19/2015 08:29 AM, Markus Armbruster wrote:
>> Ugh, I almost dropped this on the floor. I think it should go into
>> 2.5, and I plan to take it through my tree. If you disagree, please
>> speak up.
>
> It sounds like a bug fix to me (avoiding core dumps due to
> user-t
Let's think through this on a higher level.
I figure the motivation for this patch is twofold:
1. C identifier clash detection
We generate C identifiers derived from QAPI names. These can clash
with (1) each other, (2) C keywords and selected other well-known
identifiers, and (3) the u
On 11/19/2015 09:12 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> The CpuInfo struct is used only by the 'query-cpus' output
>> command, so we are free to modify it by adding fields (clients
>> are already supposed to ignore unknown output fields), or by
>> changing optional members to m
I think that's host.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1494350
Title:
QEMU: causes vCPU steal time overflow on live migration
Status in QEMU:
Fix Committed
Bug description:
I'm pa
ging
> (2015-11-18 17:07:24 +)
>
> are available in the git repository at:
>
>
> git://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-target-arm-20151119
>
> for you to fetch changes up to ce8a1b5449cd8c4c2831abb581d3208c3a3745a0:
>
> target-arm: Upda
On 11/19/2015 08:29 AM, Markus Armbruster wrote:
> Ugh, I almost dropped this on the floor. I think it should go into
> 2.5, and I plan to take it through my tree. If you disagree, please
> speak up.
It sounds like a bug fix to me (avoiding core dumps due to
user-triggerable input) and on that g
On Thu, 19 Nov 2015, Paolo Bonzini wrote:
> On 19/11/2015 16:32, Stefano Stabellini wrote:
> > > In addition to Kevin's replies, I have a high-level question: can VFIO
> > > be used by QEMU for both KVM and Xen?
> >
> > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> > is
Eric Blake writes:
> The CpuInfo struct is used only by the 'query-cpus' output
> command, so we are free to modify it by adding fields (clients
> are already supposed to ignore unknown output fields), or by
> changing optional members to mandatory, while still keeping
> QMP wire compatibility wi
On Thursday 19 November 2015 07:26 AM, Alexey Kardashevskiy wrote:
> On 11/13/2015 05:23 AM, Aravinda Prasad wrote:
>
+
+/*
+ * Currently KVM only passes on the uncorrected machine
+ * check memory error to guest. Other machine check errors
+ * such as SLB multi-hit and
Hello!
> If I read this correctly, memory regions already keep track of
> ioeventfds and this patch can simply trigger them manually if that had
> not already been done?
Yes, exactly, and this is the new idea.
> Only that we don't have such a nice tracking structure that memory
> regions alrea
Hi,
it seems that using virtio-scsi did the trick,
But now the VMs are pausing without an coredump, so the underlying Problem (no
storage Error) is not fixed,
As I am using Snapshots (and so the disks have to grow very fast) I try if
tuning "volume_utilization_percent" and "volume_utilization_ch
Apply, please.
>
>
> The following changes since commit 8f280309030331a912fd8924c129d8bd59e1bdc7:
>
> Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
> (2015-11-18 17:07:24 +)
>
> are available in the git repository at:
>
>
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On Thu, 19 Nov 2015, Jike Song wrote:
> > Hi Alex, thanks for the discussion.
> >
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with Xe
On 19/11/2015 16:32, Stefano Stabellini wrote:
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> is owned by Xen.
I don't think QEMU command line compa
On 11/19/2015 10:25 AM, Paolo Bonzini wrote:
>
>
> On 19/11/2015 16:10, Matthew Rosato wrote:
>> From: Bharata B Rao
>>
>> This sync API will be used by the CPU hotplug code to wait for the CPU to
>> completely get removed before flagging the failure to the device_add
>> command.
>>
>> Sync vers
On Thu, 19 Nov 2015, Jike Song wrote:
> Hi Alex, thanks for the discussion.
>
> In addition to Kevin's replies, I have a high-level question: can VFIO
> be used by QEMU for both KVM and Xen?
No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
is owned by Xen.
Commit 29c75dd "json-streamer: limit the maximum recursion depth and
maximum token count" attempts to guard against excessive heap usage by
limiting total token size (it says "token count", but that's a lie).
Total token size is a rather imprecise predictor of heap usage: many
small tokens use mor
We limit nesting depth and input size to defend against input
triggering excessive heap or stack memory use (commit 29c75dd
json-streamer: limit the maximum recursion depth and maximum token
count). However, when the nesting limit is exceeded,
parser_context_peek_token()'s assertion fails.
Broken
Ugh, I almost dropped this on the floor. I think it should go into
2.5, and I plan to take it through my tree. If you disagree, please
speak up.
We limit nesting depth and input size to defend against input
triggering excessive heap or stack memory use (commit 29c75dd
json-streamer: limit the ma
The nesting limit from commit 29c75dd "json-streamer: limit the
maximum recursion depth and maximum token count" applies separately to
braces and brackets. This makes no sense. Apply it to their sum,
because that's actually a measure of recursion depth.
Signed-off-by: Markus Armbruster
Reviewed
This would have prevented the regression mentioned in the previous
commit.
Signed-off-by: Markus Armbruster
Reviewed-by: Eric Blake
---
tests/check-qjson.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/tests/check-qjson.c b/tests/check-qjson.c
index 1cfffa5..61e
From: "Dr. David Alan Gilbert"
madvise() returns EINVAL in the case of many failures, but also
returns it in cases where the host kernel doesn't have THP enabled.
Postcopy only really cares that THP is off before it detects faults,
and turns it back on afterwards; so we're going to have
to assume
On 19/11/2015 16:10, Matthew Rosato wrote:
> From: Bharata B Rao
>
> This sync API will be used by the CPU hotplug code to wait for the CPU to
> completely get removed before flagging the failure to the device_add
> command.
>
> Sync version of this call is needed to correctly recover from CPU
Some passthrough'ed devices depend on clock nodes. Those need to be
generated in the guest device tree. This patch introduces some helpers
to build a clock node from information retrieved from host device tree.
- inherit_properties copies properties from a host device tree node to
a guest device
On 19/11/2015 15:21, Shmulik Ladkani wrote:
> Various fixes to what the vmw_pvscsi device reports in its PCI
> configuration space, to better align with VMware virtual hardware
> as exposed by ESXi/Workstation.
>
> Shmulik Ladkani (3):
> vmw_pvscsi: Set device subsystem and revision
> vmw_pv
I am resending this RFC from Oct 12, after kernel 4.4-rc1 and
QEMU 2.5-rc1, hoping things have calmed down a little bit.
This RFC allows to set up AMD XGBE passthrough. This was tested on AMD
Seattle.
The first upstreamed device supporting KVM platform passthrough was the
Calxeda Midway XGMAC. Co
This patch introduces the amd-xgbe VFIO platform device. It
allows the guest to do passthrough on a device exposing an
"amd,xgbe-seattle-v1a" compat string.
Signed-off-by: Eric Auger
---
hw/vfio/Makefile.objs | 1 +
hw/vfio/amd-xgbe.c | 55
Current qemu_fdt_getprop exits if the property is not found. It is
sometimes needed to read an optional property, in which case we do
not wish to exit but simply returns a null value.
This is what this new qemu_fdt_getprop_optional function does.
Signed-off-by: Eric Auger
---
device_tree.c
This patch allows the instantiation of the vfio-amd-xgbe device
from the QEMU command line (-device vfio-amd-xgbe,host="").
The guest is exposed with a device tree node that combines the description
of both XGBE and PHY (representation supported from 4.2 onwards kernel):
Documentation/devicetree/b
This function returns the host device tree blob from sysfs
(/sys/firmware/devicetree/base).
This has a runtime dependency on the dtc binary. This functionality
is useful for platform device passthrough where the host device tree
needs to be parsed to feed information into the guest device tree.
S
On 11/19/2015 07:53 AM, Andrew Jones wrote:
> dump-guest-memory is supported by more than just x86, however
> the paging option is not.
>
> (No functional change.)
>
> Signed-off-by: Andrew Jones
> ---
> qapi-schema.json | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by:
This new helper routine returns the node path of a device
referred to by its name and compat string.
Signed-off-by: Eric Auger
---
device_tree.c| 40
include/sysemu/device_tree.h | 3 +++
2 files changed, 43 insertions(+)
diff --git a/de
Changes from v1->v2:
* Remove cpu-add support. Instead use 'device_add s390-cpu'
* Add unplug support via 'device_del'.
* Pull in 2 patches from pseries set. Patch 1 just required some rebasing.
Patch 2 required minor changes due to previous upstream review comments.
**
The follo
On 11/19/2015 06:32 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> [Replace the old commit message with this:]
>>
>> qapi: Forbid case-insensitive clashes
>>
>> However, we DO have to care about the fact that we have a
>> command 'stop' and an event 'STOP' (currently the only case
>> col
In preparation for unplug, do some additional cleanup
work to undo work originally done in cpu_exec_init.
This patch is based on work done by Bharata B Rao.
Signed-off-by: Matthew Rosato
---
target-s390x/cpu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/target-s390x/cpu.
From: Bharata B Rao
This sync API will be used by the CPU hotplug code to wait for the CPU to
completely get removed before flagging the failure to the device_add
command.
Sync version of this call is needed to correctly recover from CPU
realization failures when ->plug() handler fails.
Signed-
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 19 November 2015 at 14:44, Peter Maydell wrote:
> > On 19 November 2015 at 13:21, Peter Maydell
> > wrote:
> >> On 19 November 2015 at 13:12, Peter Maydell
> >> wrote:
> >>> Hi. Unfortunately this failed in 'make check' (x86-64 Linux, debu
Introduce s390_(un)register_cpustate, which will set the
machine/cpu[n] link with the current CPU state. Additionally,
maintain an array of state pointers indexed by CPU id for fast lookup
during interrupt handling.
Signed-off-by: Matthew Rosato
---
hw/s390x/s390-virtio.c | 54 +
To clarify, the 4.4 kernel needs to be running on the VM host, not the
guests?
Thanks again!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1494350
Title:
QEMU: causes vCPU steal time overflow on l
1 - 100 of 256 matches
Mail list logo
