On Mon, Mar 2, 2020, 5:38 AM Zhoujian (jay) wrote:
>
>
> > -Original Message-
> > From: Peter Feiner [mailto:pfei...@google.com]
> > Sent: Saturday, February 22, 2020 8:19 AM
> > To: Junaid Shahid
> > Cc: Ben Gardon ; Zhoujian (jay)
> > ; Peter
rallel slow-path page faults, but it's definitely
> > faster under the MMU lock.
> >
>
> I am not sure if we ever posted those patches upstream. Peter Feiner would
> know for sure. One notable difference in what we do compared to the approach
> outlined by Jay is that w
On Fri, Oct 31, 2014 at 11:29:49AM +0800, zhanghailiang wrote:
> Agreed, but for doing live memory snapshot (VM is running when do snapsphot),
> we have to do this (block the write action), because we have to save the page
> before it
> is dirtied by writing action. This is the difference, compare
On Thu, Oct 30, 2014 at 07:31:48PM +0800, zhanghailiang wrote:
> On 2014/10/30 1:46, Andrea Arcangeli wrote:
> >On Mon, Oct 27, 2014 at 05:32:51PM +0800, zhanghailiang wrote:
> >>I want to confirm a question:
> >>Can we support distinguishing between writing and reading memory for
> >>userfault?
>
On Tue, Oct 07, 2014 at 05:52:47PM +0200, Andrea Arcangeli wrote:
> I probably grossly overestimated the benefits of resolving the
> userfault with a zerocopy page move, sorry. [...]
For posterity, I think it's worth noting that most expensive aspect of a TLB
shootdown is the interprocessor interr
On Fri, Jan 10, 2014 at 1:26 PM, Kevin Wolf wrote:
> Am 10.01.2014 um 19:05 hat Max Reitz geschrieben:
>> On 10.01.2014 18:55, Kevin Wolf wrote:
>> >Ok, if you're happy with it, I'll apply it. Can I put your Reviewed-by
>> >there?
>>
>> Yes, feel free to.
>
> Thanks, applied to the block branch.
>
lp' for more information
(qemu) info block
ide0-hd0: file-overlay.qcow2 (qcow2)
Backing file: base.file (chain depth: 1)
...
I'll take a look and report back.
On Thu, Jan 9, 2014 at 5:59 AM, Kevin Wolf wrote:
> [ CCing Max, who was recently active in this area, for another opinion ]
>
dbecebddfa4932d1c83915bcb9b5ba5984eb91be.
Signed-off-by: Peter Feiner
---
block.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 64e7d22..a4a172d 100644
--- a/block.c
+++ b/block.c
@@ -1016,8 +1016,9 @@ int bdrv_open_backing_file(BlockDriver
I had this same question. I'm not sure why it wasn't added to the mainline
qemu.git. In any case, you can get the commits and tag from git://
git.qemu.org/qemu-stable-1.4.git (git remote add stable-1.4 git://
git.qemu.org/qemu-stable-1.4.git && git fetch stable-1.4).
Peter
On Fri, May 31, 2013 a
Ping.
I'm very much hoping for this to make it into 1.5.
Thanks,
Peter
On Mon, Mar 4, 2013 at 1:54 PM, wrote:
> From: Peter Feiner
>
> Adds ramblocks' names to their backing files when using -mem-path. Eases
> introspection and debugging.
>
> Signed-off-by: P
On Fri, Mar 1, 2013 at 1:47 PM, Andreas Färber wrote:
> Am 01.03.2013 18:21, schrieb pe...@gridcentric.ca:
>
> Is it safe to use a MemoryRegion name as part of mkstemp()? "/../" seems
> rather unlikely but a "/" less so.
Since mkstemp essentially calls open, "/" does what you'd expect. So a
Memor
On Fri, Jan 25, 2013 at 8:08 AM, Andreas Färber wrote:
> We just need to be aware that inspecting register values is one thing,
> but that letting QMP qom-set arbitrary registers during runtime could
> cause unpredictable issues. Checks on dev->realized could be added as
> precaution (cf. qdev sta
> What about converting 'info registers' to QMP (ie. having
> query-cpu-registers)?
We had thought about it, but we decided to go with this lower hanging fruit
because it provides immediately useful functionality at a low implementation
cost. It's harder (for us) to think of why would anyone want
On Wed, Jan 23, 2013 at 4:49 PM, Eric Blake wrote:
> Might be worth mentioning that this field (and the others) was added in 1.4.
Thanks Eric. I'll put that in V2.
> This is not reasonable IMHO.
>
> I was okay with sticking a name on a ramblock, but encoding a guest PA
> offset turns this into a supported ABI which I'm not willing to do.
>
> A one line change is one thing, but not a complex new option that
> introduces an ABI only for a proprietary product th
On Tue, Nov 20, 2012 at 7:10 AM, Peter Feiner wrote:
>
> This patch proposes a framework that empowers QEMU to implement powerful
> memory
> management techniques with very low cost. The insight is to leverage existing
> sub-systems, composing functionality in a traditional UNIX
Ping?
P.S. Please note a typo in the cover letter: when I referred to KSM, I
meant "kernel samepage merging", not "kernel shared memory" :-)
On Tue, Nov 20, 2012 at 7:10 AM, Peter Feiner wrote:
> This patch makes the -mem-path filenames deterministic and allows some
&g
implementation with deterministic
file names and control over mmap flags, QEMU enables efficient VM cloning.
Moreover, novel memory-management techniques can be implemented without adding
any complexity to QEMU. For example, the example becomes post-copy live
migration if /t
rministic name and unlinks the files.
Signed-off-by: Peter Feiner
---
cpu-all.h |5
exec.c | 60 ++
qemu-config.c | 26 +++
qemu-options.hx | 24 +++
Hi,
Is there any interest in this feature?
BTW, as far as I can tell, on qemu-devel I'm not supposed to re-post
the patch or post a v2 if there haven't been any specific requests for
changes to v1. Please let me know if you'd like me to submit a new
patch!
Thanks,
Peter Feiner
>> Do you have any performance number for this? And examples on how your
>> are using it?
> Our principal use case is implementing VM migration techniques.
There are other uses of a RAM file interface that I can imagine:
- debugging, e.g., inspecting the memory of a VM after it has crashed
- se
> Hi
Hi Juan,
Sorry for taking so long to reply -- my email filters apparently
aren't setup correctly!
> Do you have any performance number for this? And examples on how your
> are using it?
The performance should depend only on the VMA backing the file, in
addition to any indirect overhead ca
Enables providing a backing file for the PC's ram. The file is specified by the
new -pcram-file option. The file is mmap'd shared, so the RAMBlock that it backs
doesn't need to be saved by vm_save / migration.
Signed-off-by: Peter Feiner
---
We have found this small feature
23 matches
Mail list logo
