More bugs: addl/v should sign-extend the result, as addl does.
As it is, we have
uint64_t helper_addlv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
{
uint64_t tmp = op1;
op1 = (uint32_t)(op1 + op2);
if (unlikely((tmp ^ op2 ^ (-1UL)) & (tmp ^ op1) & (1UL << 31))) {
ari
On Thu, Jul 03, 2014 at 02:10:55PM +0800, Hu Tao wrote:
> Introduce memory_region_init_ram_nofail() and
> memory_region_init_ram_ptr_nofail(), which are the same as
> memory_region_init_ram() and memory_region_init_ram_ptr()
> respectively. They will exit qemu if there is an error, this is the
> be
Alexey Kardashevskiy writes:
> diff --git a/hw/core/nmi.c b/hw/core/nmi.c
> new file mode 100644
> index 000..db1295f
> --- /dev/null
> +++ b/hw/core/nmi.c
> @@ -0,0 +1,84 @@
[...]
> +
> +static void nmi_children(Object *o, struct do_nmi_s *ns);
> +
[...]
> +
> +void nmi_children(Object *o
On Thu, Jul 03, 2014 at 01:57:24PM +0800, Chen, Tiejun wrote:
> On 2014/7/2 23:27, Michael S. Tsirkin wrote:
> >On Wed, Jul 02, 2014 at 03:15:02PM +, Ross Philipson wrote:
> >>>-Original Message-
> >>>From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> >>>Sent: Wednesday, July 02, 2014 7
I can confirm that it's more kernel issue than qemu. I run kernel
3.11.0-24-generic which is left after upgrade from Saucy and have no
issues for at least two days. Before that with current 3.13.0-30-generic
kernel my Windows guests crashed every 3-4 hours.
--
You received this bug notification b
Introduce memory_region_init_ram_nofail() and
memory_region_init_ram_ptr_nofail(), which are the same as
memory_region_init_ram() and memory_region_init_ram_ptr()
respectively. They will exit qemu if there is an error, this is the
behaviour of old memory_region_init_ram() and
memory_region_init_ram
This patch fixes two problems of memory-backend-file:
1. If user adds a memory-backend-file object using object_add command,
specifying a non-existing directory for property mem-path, qemu
will core dump with message:
/nonexistingdir: No such file or directory
Bad ram offset f
This series includes two patches to fix bugs of memory backend. See each
patch for the bugs and how to reproduce them.
Hu Tao (2):
memory: introduce memory_region_init_ram_nofail() and
memory_region_init_ram_ptr_nofail()
memory-backend-file: improve error handling
backends/hostmem-ram.c
After installing kernel 3.15.1-031501-generic from kernel-ppa, both
machines work without issues from 2014-06-25. Seems it's kernel issue
that have already been solved upstream.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
On 2014/7/2 23:27, Michael S. Tsirkin wrote:
On Wed, Jul 02, 2014 at 03:15:02PM +, Ross Philipson wrote:
-Original Message-
From: Paolo Bonzini [mailto:pbonz...@redhat.com]
Sent: Wednesday, July 02, 2014 7:33 AM
To: Ross Philipson; Michael S. Tsirkin; Stefano Stabellini
Cc: peter.may
>>> On 7/2/2014 at 11:17 PM, in message
<21428.8829.273127.394...@mariner.uk.xensource.com>, Ian Jackson
wrote:
> Ian Campbell writes ("Re: [RFC PATCH V3 1/2] xen: pass kernel initrd to
> qemu"):
> > On Mon, 2014-06-23 at 15:22 +0100, Ian Jackson wrote:
> > > If we are going to do this then
Hi,
Sorry that I forgot to send a follow-up patch to this one, I'll resend
this patch with the follow-up.
Regards,
Hu
Alexey Kardashevskiy writes:
> On 06/30/2014 06:35 PM, Nikunj A Dadhania wrote:
>> PAPR compliant guest calls this in absence of kdump. This finally
>> reaches the guest and can be handled according to the policies set by
>> higher level tools(like taking dump) for further analysis by tools like
On 06/23/2014 11:32 PM, Alexey Kardashevskiy wrote:
> On 06/16/2014 06:37 PM, Alexander Graf wrote:
>>
>> On 16.06.14 10:33, Alexey Kardashevskiy wrote:
>>> On 06/16/2014 05:16 PM, Cornelia Huck wrote:
On Sat, 14 Jun 2014 12:41:50 +1000
Alexey Kardashevskiy wrote:
> On 06/13/201
On Thu, Jul 3, 2014 at 12:21 AM, Paolo Bonzini wrote:
> Il 02/07/2014 17:45, Ming Lei ha scritto:
>> The attachment debug patch skips aio_notify() if qemu_bh_schedule
>> is running from current aio context, but looks there is still 120K
>> writes triggered. (without the patch, 400K can be observed
On Wednesday, July 2, 2014 8:12:17 PM CDT, yue wrote:
could you tell me why 'Qemu doesn't handle that level of abstraction'?
i know qcow2 well, you can tell me the comparation。
Qemu would have to have a lot of extra code (that already exists elsewhere)
to support taking snapshots/clones/etc o
>>> On 7/2/2014 at 09:03 PM, in message <53b4031e.3030...@redhat.com>, Eric
>>> Blake
wrote:
> On 07/02/2014 03:50 AM, Chunyan Liu wrote:
> > Add nocow info in 'qemu-img info' output to show whether the file
> > currently has NOCOW flag set or not.
> >
> > Signed-off-by: Chunyan Liu
> >
On 07/03/2014 01:41 PM, Alexey Kardashevskiy wrote:
> On 06/30/2014 06:35 PM, Nikunj A Dadhania wrote:
>> PAPR compliant guest calls this in absence of kdump. This finally
>> reaches the guest and can be handled according to the policies set by
>> higher level tools(like taking dump) for further an
Hi David,
On 07/01/2014 08:12 PM, Dr. David Alan Gilbert wrote:
* Hongyang Yang (yan...@cn.fujitsu.com) wrote:
Hi Yang,
Background:
COLO HA project is a high availability solution. Both primary
VM (PVM) and secondary VM (SVM) run in parallel. They receive the
same request from client, and
On 06/30/2014 06:35 PM, Nikunj A Dadhania wrote:
> PAPR compliant guest calls this in absence of kdump. This finally
> reaches the guest and can be handled according to the policies set by
> higher level tools(like taking dump) for further analysis by tools like
> crash.
>
> Linux kernel calls ibm
This moves recurring bits of code related to memory@xxx nodes
creation to a helper.
This makes use of the new helper for node@0.
Signed-off-by: Alexey Kardashevskiy
---
hw/ppc/spapr.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff
In multiple places there is a node0_size variable calculation
which assumes that NUMA node #0 and memory node #0 are the same
things which they are not. Since we are going to change it and
do not want to change it in multiple places, let's make a helper.
This adds a spapr_node0_size() helper and m
This finishes refactoring by using the spapr_populate_memory_node helper
for all nodes and removing leftovers from spapr_populate_memory().
This is not a part of the previous patch because the patches look
nicer apart.
Signed-off-by: Alexey Kardashevskiy
---
hw/ppc/spapr.c | 19 ++--
We want the associtivity lists of memory and CPU nodes to match but
memory nodes have incorrect domain#3 which is zero for CPU so they won't
match.
This clears domain#3 in the list to match CPUs associtivity lists.
Signed-off-by: Alexey Kardashevskiy
---
hw/ppc/spapr.c | 2 +-
1 file changed, 1
Linux kernel expects nodes to have power-of-two size and
does WARN_ON if this is not the case:
[0.041456] WARNING: at drivers/base/memory.c:115
which is:
===
/* Validate blk_sz is a power of 2 and not less than section size */
if ((block_sz & (block_sz - 1)) || (block_sz < MIN_M
c4177479 "spapr: make sure RMA is in first mode of first memory node"
introduced regression which prevents from running guests with memoryless
NUMA node#0 which may happen on real POWER8 boxes and which would make
sense to debug in QEMU.
This patchset aim is to fix that and also fix various code
Current QEMU does not support memoryless NUMA nodes, however
actual hardware may have them so it makes sense to have a way
to emulate them in QEMU. This prepares SPAPR for that.
This moves 2 calls of spapr_populate_memory_node() into
the existing loop over numa nodes so first several nodes may
hav
Is that about correct?
What are folks timezones and the best days next week to talk about
this on either Google Hangout or the phone?
UK timezone. Maybe Friday afternoon so that afterwards we can go have
enough beers to forget about all this.
Is this determined formally?
I mean I can ask i
>>> On 7/2/2014 at 11:16 PM, in message
<1404314181.8137.7.ca...@kazak.uk.xensource.com>, Ian Campbell
wrote:
> On Tue, 2014-07-01 at 15:06 +0800, Chunyan Liu wrote:
> > xen side patch to support xen HVM direct kernel boot:
> > support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as we
On 2014/7/2 20:19, Paolo Bonzini wrote:
> Il 02/07/2014 13:57, ChenLiang ha scritto:
Hmm, dbs->in_cancel will be true always. Although this will avoid freeing
dbs by dma_comlete.
But it maybe a mistake.
>>>
>>> This was on purpose; I'm doing the free myself in dma_aio_cancel, so I
On 07/02/2014 09:50 AM, Andrea Arcangeli wrote:
> Once an userfaultfd is created MADV_USERFAULT regions talks through
> the userfaultfd protocol with the thread responsible for doing the
> memory externalization of the process.
>
> The protocol starts by userland writing the requested/preferred
>
On 07/02/2014 09:50 AM, Andrea Arcangeli wrote:
> Hello everyone,
>
> There's a large CC list for this RFC because this adds two new
> syscalls (userfaultfd and remap_anon_pages) and
> MADV_USERFAULT/MADV_NOUSERFAULT, so suggestions on changes to the API
> or on a completely different API if someb
could you tell me why 'Qemu doesn't handle that level of abstraction'?
i know qcow2 well, you can tell me the comparation。
thanks
At 2014-07-02 11:36:12, "Brian Jackson" wrote:
>Qemu doesn't handle that level of abstraction. The closest approximation
>you could probably come up with is
On 07/02/2014 06:29 PM, Gary Jordan wrote:
[please don't top-post on technical lists]
> If I open two session in a migration operation, how does the qemu know
> which one should be accepted? I saw there was a ram_list to check, but no
> id of the guest.
I suggest using higher level software, lik
If I open two session in a migration operation, how does the qemu know
which one should be accepted? I saw there was a ram_list to check, but no
id of the guest.
2014-07-02 17:59 GMT-04:00 Eric Blake :
> On 07/02/2014 01:20 PM, Gary Jordan wrote:
> > Does Qemu have a VM id allocated for each VM?
On Wed, Jul 02, 2014 at 05:14:26PM -0400, Gabriel L. Somlo wrote:
> On Wed, Jul 02, 2014 at 11:02:30PM +0200, Alexander Graf wrote:
> >
> > On 02.07.14 22:49, Gabriel L. Somlo wrote:
> > >So it turns out everything I thought I knew (which was little indeed)
> > >was more or less wrong. The problem
On 07/02/2014 01:20 PM, Gary Jordan wrote:
> Does Qemu have a VM id allocated for each VM? I did not find this Id in
> qemu. HOW deos qemu identify each VM, using thread Id or some other
> identifiers?
Each qemu process manages exactly one VM, so qemu doesn't care what id a
guest has. Higher-lev
> Am 02.07.2014 um 23:14 schrieb "Gabriel L. Somlo" :
>
>> On Wed, Jul 02, 2014 at 11:02:30PM +0200, Alexander Graf wrote:
>>
>>> On 02.07.14 22:49, Gabriel L. Somlo wrote:
>>> So it turns out everything I thought I knew (which was little indeed)
>>> was more or less wrong. The problem, as far
On Wed, Jul 02, 2014 at 02:02:14PM -0700, Nishanth Aravamudan wrote:
> On 02.07.2014 [15:21:38 -0300], Eduardo Habkost wrote:
> > On Tue, Jul 01, 2014 at 01:50:06PM -0700, Nishanth Aravamudan wrote:
> > > On 01.07.2014 [17:39:57 -0300], Eduardo Habkost wrote:
> > > > On Tue, Jul 01, 2014 at 01:13:2
On Wed, Jul 02, 2014 at 11:02:30PM +0200, Alexander Graf wrote:
>
> On 02.07.14 22:49, Gabriel L. Somlo wrote:
> >So it turns out everything I thought I knew (which was little indeed)
> >was more or less wrong. The problem, as far as I'm observing it now,
> >is that on PIIX, the OS X guest obsessi
On 02.07.2014 [15:21:38 -0300], Eduardo Habkost wrote:
> On Tue, Jul 01, 2014 at 01:50:06PM -0700, Nishanth Aravamudan wrote:
> > On 01.07.2014 [17:39:57 -0300], Eduardo Habkost wrote:
> > > On Tue, Jul 01, 2014 at 01:13:28PM -0700, Nishanth Aravamudan wrote:
> > > [...]
> > > > diff --git a/hw/i38
On 02.07.14 22:49, Gabriel L. Somlo wrote:
On Wed, Jul 02, 2014 at 11:16:52AM +0200, Alexander Graf wrote:
Are you sure there's not just simply some irq unmasking event
after 5500ms we don't handle properly?
I poked around a bit, and the e1000 interrupt mask register is NOT the
problem (the LS
On 02.07.14 21:34, Scott Wood wrote:
On Wed, 2014-07-02 at 19:59 +0200, Alexander Graf wrote:
On 02.07.14 19:52, Scott Wood wrote:
On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote:
On 02.07.14 19:26, Scott Wood wrote:
On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
On 02.07.
On Wed, Jul 02, 2014 at 11:16:52AM +0200, Alexander Graf wrote:
>>> Are you sure there's not just simply some irq unmasking event
>>> after 5500ms we don't handle properly?
>> I poked around a bit, and the e1000 interrupt mask register is NOT the
>> problem (the LSC mask bit is clear at all times).
On Wed, 2014-07-02 at 19:59 +0200, Alexander Graf wrote:
> On 02.07.14 19:52, Scott Wood wrote:
> > On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote:
> >> On 02.07.14 19:26, Scott Wood wrote:
> >>> On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
> On 02.07.14 00:50, Scott Wood
On Wed, 2014-07-02 at 18:12 +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try summarizing
Does Qemu have a VM id allocated for each VM? I did not find this Id in
qemu. HOW deos qemu identify each VM, using thread Id or some other
identifiers?
On Tue, Jul 01, 2014 at 01:50:06PM -0700, Nishanth Aravamudan wrote:
> On 01.07.2014 [17:39:57 -0300], Eduardo Habkost wrote:
> > On Tue, Jul 01, 2014 at 01:13:28PM -0700, Nishanth Aravamudan wrote:
> > [...]
> > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > > index 12472c6..cdefafe 100644
> > > -
We messed up the ordering in our default configs for PPC. The top entries
are generic entries, then come sections that indicate that features are only
in because of a special feature (such as PReP).
Fix the ordering again and while at it add eTSEC support to the ppc64 target
so that we can spawn e
We have helper functions to easily expose integers as QOM object properties.
However, these are read only.
This patch makes the getter function world accessible and adds a generic
setter for integer properties.
We can use these later with the generic object_property_add to not dupliate
simple log
We want to give the user the ability to tell our machine file where he wants
to have devices mapped to. This patch adds code to create these hints
dynamically and expose them as object properties that can only be modified
before device realization.
Signed-off-by: Alexander Graf
---
v1 -> v2:
A good amount of properties are really just g_new / g_malloc allocated memory.
There's no reason we need to have different release helpers for all of those.
This patch introduces a new g_free() based helper for property release and
replaces existing duplicated code implementations in object.c as w
We have accumulated a number of friendly helpers that make registration
of properties easier. However, their number is only increasing and they
start to clutter the core object.c file.
So let's move them into a separate C file and thus ensure that we have
room to grow :).
Signed-off-by: Alexander
Now that we can properly map sysbus devices that haven't been connected to
something forcefully by C code, we can allow the -device command line option
to spawn them.
For machines that don't implement dynamic sysbus assignment in their board
files we add a new bool "has_dynamic_sysbus" to the mach
For e500 our approach to supporting dynamically spawned sysbus devices is to
create a simple bus from the guest's point of view within which we map those
devices dynamically.
We allocate memory regions always within the "platform" hole in address
space and map IRQs to predetermined IRQ lines that
This patch adds support to expose eTSEC devices in the dynamically created
guest facing device tree. This allows us to expose eTSEC devices into guests
without changes in the machine file.
Because we can now tell the guest about eTSEC devices this patch allows the
user to specify eTSEC devices via
We have a bunch of nice helpers that allow us to easily register an integer
field as QOM property. However, we have those duplicated for every integer
size available.
This is very cumbersome (and prone to bugs) to work with and extend, so let's
strip out the only difference there is (the size) and
Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
device creation world of QEMU. Devices on these were modeled as SysBus devices
which can only be instantiated in machine files, not through -device.
Why is that so?
For Sysbus devices we didn't know who should be respo
On 02.07.14 19:52, Scott Wood wrote:
On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote:
On 02.07.14 19:26, Scott Wood wrote:
On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
On 02.07.14 00:50, Scott Wood wrote:
Plus, let's please not hardcode any more addresses that are going t
On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right. Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly t
On Wed, Jul 02, 2014 at 12:05:27PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > > Il 01/
On Wed, 2014-07-02 at 19:30 +0200, Alexander Graf wrote:
> On 02.07.14 19:26, Scott Wood wrote:
> > On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
> >> On 02.07.14 00:50, Scott Wood wrote:
> >>> Plus, let's please not hardcode any more addresses that are going to be
> >>> a problem for gi
On 02.07.14 19:32, Scott Wood wrote:
On Wed, 2014-07-02 at 19:24 +0200, Alexander Graf wrote:
On 02.07.14 00:56, Scott Wood wrote:
On Tue, 2014-07-01 at 23:49 +0200, Alexander Graf wrote:
This patch adds support to expose eTSEC devices in the dynamically created
guest facing device tree. This
On Wed, 2014-07-02 at 19:24 +0200, Alexander Graf wrote:
> On 02.07.14 00:56, Scott Wood wrote:
> > On Tue, 2014-07-01 at 23:49 +0200, Alexander Graf wrote:
> >> This patch adds support to expose eTSEC devices in the dynamically created
> >> guest facing device tree. This allows us to expose eTSEC
On 02.07.14 19:26, Scott Wood wrote:
On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
On 02.07.14 00:50, Scott Wood wrote:
Plus, let's please not hardcode any more addresses that are going to be
a problem for giving guests a large amount of RAM (yes, CCSRBAR is also
blocking that, but
On Wed, 2014-07-02 at 19:12 +0200, Alexander Graf wrote:
> On 02.07.14 00:50, Scott Wood wrote:
> > Plus, let's please not hardcode any more addresses that are going to be
> > a problem for giving guests a large amount of RAM (yes, CCSRBAR is also
> > blocking that, but that has a TODO to parameter
On 02.07.14 00:56, Scott Wood wrote:
On Tue, 2014-07-01 at 23:49 +0200, Alexander Graf wrote:
This patch adds support to expose eTSEC devices in the dynamically created
guest facing device tree. This allows us to expose eTSEC devices into guests
without changes in the machine file.
Because we
Those two helpers are needed by remap_anon_pages.
Signed-off-by: Andrea Arcangeli
---
include/linux/mm.h | 4
mm/fremap.c| 29 +
2 files changed, 33 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 00faeda..0a7f0e1 100644
--- a/i
We were truncating physical addresses to 32bit when using qemu-system-ppc
with a booke206 TLB implementation. This patch fixes that and makes the full
address space available.
Signed-off-by: Alexander Graf
---
target-ppc/mmu_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
d
On 02.07.14 00:50, Scott Wood wrote:
On Tue, 2014-07-01 at 23:49 +0200, Alexander Graf wrote:
For e500 our approach to supporting dynamically spawned sysbus devices is to
create a simple bus from the guest's point of view within which we map those
devices dynamically.
We allocate memory region
This new syscall will move anon pages across vmas, atomically and
without touching the vmas.
It only works on non shared anonymous pages because those can be
relocated without generating non linear anon_vmas in the rmap code.
It is the ideal mechanism to handle userspace page faults. Normally
the
Once an userfaultfd is created MADV_USERFAULT regions talks through
the userfaultfd protocol with the thread responsible for doing the
memory externalization of the process.
The protocol starts by userland writing the requested/preferred
USERFAULT_PROTOCOL version into the userfault fd (64bit writ
This optimizes the userfault handler to repeat the fault without
returning to userland if it's a page faults and it teaches it to
handle FOLL_NOWAIT if it's a nonblocking gup invocation from KVM. The
FOLL_NOWAIT part is actually more than an optimization because if
FOLL_NOWAIT is set the gup caller
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try su
Hello everyone,
There's a large CC list for this RFC because this adds two new
syscalls (userfaultfd and remap_anon_pages) and
MADV_USERFAULT/MADV_NOUSERFAULT, so suggestions on changes to the API
or on a completely different API if somebody has better ideas are
welcome now.
The combination of th
Provide a new swapfile method for remap_anon_pages to verify the swap
entry is mapped only in one vma before relocating the swap entry in a
different virtual address. Otherwise if the swap entry is mapped
in multiple vmas, when the page is swapped back in, it could get
mapped in a non linear way in
remap_anon_pages (unlike remap_file_pages) tries to be non intrusive
in the rmap code.
As far as the rmap code is concerned, rmap_anon_pages only alters the
page->mapping and page->index. It does it while holding the page
lock. However there are a few places that in presence of anon pages
are allo
It is generally inefficient to ask the wakeup of userfault ranges
where there's not a single userfault address read through
userfaultfd_read earlier and in turn waiting a wakeup. However it may
come handy to wakeup the same userfault range twice in case of
multiple thread faulting on the same addre
Userfaultfd needs to wake all waitqueues (pass 0 as nr parameter),
instead of the current hardcoded 1 (that would wake just the first
waitqueue in the head list).
Signed-off-by: Andrea Arcangeli
---
include/linux/wait.h | 5 +++--
kernel/sched/wait.c | 7 ---
net/sunrpc/sched.c | 2 +-
3
MADV_USERFAULT is a new madvise flag that will set VM_USERFAULT in the
vma flags. Whenever VM_USERFAULT is set in an anonymous vma, if
userland touches a still unmapped virtual address, a sigbus signal is
sent instead of allocating a new page. The sigbus signal handler will
then resolve the page fa
We run out of 32bits in vm_flags, noop change for 64bit archs.
Signed-off-by: Andrea Arcangeli
---
fs/proc/task_mmu.c | 4 ++--
include/linux/huge_mm.h | 4 ++--
include/linux/ksm.h | 4 ++--
include/linux/mm_types.h | 2 +-
mm/huge_memory.c | 2 +-
mm/ksm.c |
On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right. Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly t
Reviewed-by: Greg Bellows
On 2 July 2014 09:07, Peter Maydell wrote:
> Make the vexpress-a9 board alias the first NOR flash region at
> address zero, like vexpress-a15. This makes "-bios" actually usable
> on this board.
>
> Signed-off-by: Peter Maydell
> ---
> Looking back through the archiv
On Thu, Jul 3, 2014 at 12:38 AM, Paolo Bonzini wrote:
>
>> On Thu, Jul 3, 2014 at 12:23 AM, Paolo Bonzini wrote:
>> > Il 02/07/2014 18:13, Ming Lei ha scritto:
>> >
>> >> That must be for generating guest irq, which should have been
>> >> processed as batch easily.
>> >
>> >
>> > No, guest irqs a
On 07/02/2014 01:13 AM, Puneet Bakshi wrote:
> Hi,
>
> I am running qemu guest agent in Windows 2k8. I am able to execute
> "qemu-agent-commands" using socat but not through "virsh
> qemu-agent-command".
>
> *Host CentOS system*
>
> socat returns response appropriately.
> [root@sdsr720-14 ~
> On Thu, Jul 3, 2014 at 12:23 AM, Paolo Bonzini wrote:
> > Il 02/07/2014 18:13, Ming Lei ha scritto:
> >
> >> That must be for generating guest irq, which should have been
> >> processed as batch easily.
> >
> >
> > No, guest irqs are generated (with notify_guest) on every I/O completion
> > eve
Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> At some level, maybe Paolo is right. Ignore existing drivers and ask
> intel developers to update their drivers to do something sane on
> hypervisors, even if they do ugly things on real hardware.
>
> A simple proposal since what I wrote earli
Il 02/07/2014 18:23, Konrad Rzeszutek Wilk ha scritto:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 651e65e..03f2829 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_devi
On Thu, Jul 3, 2014 at 12:23 AM, Paolo Bonzini wrote:
> Il 02/07/2014 18:13, Ming Lei ha scritto:
>
>> That must be for generating guest irq, which should have been
>> processed as batch easily.
>
>
> No, guest irqs are generated (with notify_guest) on every I/O completion
> even in 2.0.
In 2.0,
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >With this long thread I lost a bit context about the challenges
> >that exists. But let me try summarizing it here - which will hopefully
> >get some consensus.
> >
> >1). Fix
Il 02/07/2014 18:13, Ming Lei ha scritto:
That must be for generating guest irq, which should have been
processed as batch easily.
No, guest irqs are generated (with notify_guest) on every I/O completion
even in 2.0.
Paolo
Il 02/07/2014 17:45, Ming Lei ha scritto:
> The attachment debug patch skips aio_notify() if qemu_bh_schedule
> is running from current aio context, but looks there is still 120K
> writes triggered. (without the patch, 400K can be observed in
> same test)
Nice. Another observation is that after a
On Wed, Jul 2, 2014 at 11:45 PM, Ming Lei wrote:
> On Wed, Jul 2, 2014 at 4:54 PM, Stefan Hajnoczi wrote:
>> On Tue, Jul 01, 2014 at 06:49:30PM +0200, Paolo Bonzini wrote:
>>> Il 01/07/2014 16:49, Ming Lei ha scritto:
>>> >Let me provide some data when running randread(bs 4k, libaio)
>>> >from VM
On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > >
> > > >We do IGD pass-through
On 07/02/2014 09:03 AM, Paolo Bonzini wrote:
What if an underlying device doesn't support [rw]error=stop? Not all
do...
>>>
>>> Then the "fix" is to add support to the underlying device. IDE, SCSI
>>> and virtio-blk (plus virtio-scsi via SCSI of course) are covered;
>>
>> Where "covere
On Wed, Jul 02, 2014 at 08:26:53AM -0700, Richard Henderson wrote:
> On 07/01/2014 11:17 PM, Al Viro wrote:
> > If we don't want FE_INEXACT seen by fetestexcept() after rounding 4.5, we'd
> > better not use FPCR.INE - *all* variants of actual hardware (at least from
> > 21064A to 21264) set that su
On Wed, Jul 2, 2014 at 4:54 PM, Stefan Hajnoczi wrote:
> On Tue, Jul 01, 2014 at 06:49:30PM +0200, Paolo Bonzini wrote:
>> Il 01/07/2014 16:49, Ming Lei ha scritto:
>> >Let me provide some data when running randread(bs 4k, libaio)
>> >from VM for 10sec:
>> >
>> >1), qemu.git/master
>> >- write():
Qemu doesn't handle that level of abstraction. The closest approximation
you could probably come up with is qemu-img's backing file support for
qcow2 images.
You should stick to using the rbd tool to create clones of rbd devices.
Alternatively, use a higher level tool (like openstack, etc) tha
On 02.07.14 08:32, Paolo Bonzini wrote:
Il 01/07/2014 23:49, Alexander Graf ha scritto:
+
+static void machine_init_notify(Notifier *notifier, void *data)
+{
+Object *machine = qdev_get_machine();
+Object *container;
+
+if (object_property_find(machine, "has-dynamic-sysbus", NULL))
hi,all
i now look at qemu 2.0, i do not find rbd-api related to clone.
if qemu support this function? and from which version?
clone api of rbd is very simple(one api), why qemu does not implement?what is
the reason?
thanks.
1 - 100 of 263 matches
Mail list logo