search for: dirtying

Greetings All, Without going into the specific reasons why I need to do so, is anyone aware of a method (or tool) of watching real-time, human-readable (or system call print) of ext3 filesystem operations on a mounted, active filesystem? Excuse me if this is a duplicate question but I was unable to find any similar ones in the archives. Thanks in advance! Kevin Strong Criminal Information

From: Michel Dänzer <michel.daenzer at amd.com> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com> --- Chris / Ilia / Ben, this should be manageable for the intel/nouveau drivers, right? src/amdgpu_drv.h | 26 ++++++++++++++++++++++++++ src/amdgpu_kms.c | 18 +++++++++--------- src/drmmode_display.c | 8 ++++++-- 3 files changed, 41 insertions(+), 11 deletions(-)

From: Michel Dänzer <michel.daenzer at amd.com> This allows making the master screen's pixmap_dirty_list entries explicitly reflect that we're now tracking the root window instead of the screen pixmap, in order to allow Present page flipping on master outputs while there are active slave outputs. Define HAS_DIRTYTRACKING_DRAWABLE_SRC for drivers to check, but leave

Add hypercall (shadow op: enable/disable and clean/peek dirtied page bitmap). It consists of two parts: dirty page detecting and saving. For detecting, we setup the guest p2m''s leaf PTE read-only and whenever the guest tries to write something, permission fault happens and traps into xen. The permission-faulted GPA should be saved for the toolstack (when it wants to see which pages

Hello, i have two xen hosts servers configured to support migration of domus, but when i try to migrate, the command never ends, i can see on the remote server the machine with xm list but the machine is not accesible, and on the own server i see migrating-{machine_name} and i have access to it. Every server have one nic, with public ip (that is using with xenbr0), and i have a virbr0 configured

On 05.02.20 10:00, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:57 PM, David Hildenbrand wrote: >>>> Yes, I agree with you. Yet, I am thinking about one >>>> (unlikely?impossible?) scenario. Can you refresh my brain why that >>>> cannot happen (IOW, why we don't have to wait for the host to process >>>> the request)? >>>>

On 05.02.20 10:00, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:57 PM, David Hildenbrand wrote: >>>> Yes, I agree with you. Yet, I am thinking about one >>>> (unlikely?impossible?) scenario. Can you refresh my brain why that >>>> cannot happen (IOW, why we don't have to wait for the host to process >>>> the request)? >>>>

Hello, I have two computers, one with Ubuntu 14.04 and one with Ubuntu 16.04. On both computers I have configured the printer with cups to print by using my Kerberos credential in the same way and it works in 14.04 but not on 16.04. For both /usr/bin/smbspool_krb5_wrapper is 700 and I have "AuthInfoRequired negotiate" for both in /etc/cups/printers.conf. I have made a symbolic link

Now that we have implemented systemd socket activation, we can use this to run qemu-nbd in tests. The first patch leaves some dead code around (the -DSERVE_OVER_TCP=1 path). It's possible we might want to use this to test against a putative future NBD server that only supports TCP, but on the other hand maybe we should just remove it. Tests & valgrind still pass for me. Rich.

>> 1. Guest allocates a page and sends it to the host. >> 2. Shrinker gets active and releases that page again. >> 3. Some user in the guest allocates and modifies that page. The dirty bit is >> set in the hypervisor. > > The bit will be set in KVM's bitmap, and will be synced to QEMU's bitmap when the next round starts. > >> 4. The host processes

>> 1. Guest allocates a page and sends it to the host. >> 2. Shrinker gets active and releases that page again. >> 3. Some user in the guest allocates and modifies that page. The dirty bit is >> set in the hypervisor. > > The bit will be set in KVM's bitmap, and will be synced to QEMU's bitmap when the next round starts. > >> 4. The host processes

Here''s a question about FE driver and log dirty, when live migration is concerned. Log dirty mode is used in live migration, which works for those polluted pages from CPU issued accesses, but not for DMA path (as BE driver talked here which access from another domain like dom0). Most frontend drivers don''t implement their own suspend interface (netfront implements when

* Li, Liang Z (liang.z.li at intel.com) wrote: > > On Mon, Mar 14, 2016 at 05:03:34PM +0000, Dr. David Alan Gilbert wrote: > > > * Li, Liang Z (liang.z.li at intel.com) wrote: > > > > > > > > > > Hi, > > > > > I'm just catching back up on this thread; so without reference > > > > > to any particular previous mail in

* Li, Liang Z (liang.z.li at intel.com) wrote: > > On Mon, Mar 14, 2016 at 05:03:34PM +0000, Dr. David Alan Gilbert wrote: > > > * Li, Liang Z (liang.z.li at intel.com) wrote: > > > > > > > > > > Hi, > > > > > I'm just catching back up on this thread; so without reference > > > > > to any particular previous mail in

On Mon, Mar 14, 2016 at 05:03:34PM +0000, Dr. David Alan Gilbert wrote: > * Li, Liang Z (liang.z.li at intel.com) wrote: > > > > > > Hi, > > > I'm just catching back up on this thread; so without reference to any > > > particular previous mail in the thread. > > > > > > 1) How many of the free pages do we tell the host about? >

On Mon, Mar 14, 2016 at 05:03:34PM +0000, Dr. David Alan Gilbert wrote: > * Li, Liang Z (liang.z.li at intel.com) wrote: > > > > > > Hi, > > > I'm just catching back up on this thread; so without reference to any > > > particular previous mail in the thread. > > > > > > 1) How many of the free pages do we tell the host about? >

On 05.02.20 09:54, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:19 PM, David Hildenbrand wrote: >> Yes, I agree with you. Yet, I am thinking about one >> (unlikely?impossible?) scenario. Can you refresh my brain why that cannot >> happen (IOW, why we don't have to wait for the host to process the >> request)? >> >> 1. Guest allocates a page and

On 05.02.20 09:54, Wang, Wei W wrote: > On Wednesday, February 5, 2020 4:19 PM, David Hildenbrand wrote: >> Yes, I agree with you. Yet, I am thinking about one >> (unlikely?impossible?) scenario. Can you refresh my brain why that cannot >> happen (IOW, why we don't have to wait for the host to process the >> request)? >> >> 1. Guest allocates a page and

This patch series silences some unknown cap warnings and fixes up coding style (patch 1+4). The most important part of this series are the two patches in the middle. They rework the state_fb code, so that we are able to render to not 64 byte aligned targets, as this is the only real use-case for render temporaries this allows us to drop temp code completely and simplifies a lot

Write dirty block groups may allocate new block, thus may add new delayed back ref. btrfs_run_delayed_refs may make some block groups dirty. commit_cowonly_roots does not handle the recursion properly, so some dirty blocks can be left unwritten at commit time. This patch move btrfs_run_delayed_refs into the loop that writes dirty block groups, and make the code not break out of the loop until