| Message ID | 20200403165657.20566-1-yan.y.zhao@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drop writes to read-only ram device & vfio regions | expand |
Forgot the changelog, so sent this patch 0/3 again. sorry about that. On Sat, Apr 04, 2020 at 01:08:23AM +0800, Zhao, Yan Y wrote: > patch 1 modifies handler of ram device memory regions to drop guest writes > to read-only ram device memory regions > > patch 2 modifies handler of non-mmap'd read-only vfio regions to drop guest > writes to those regions > > patch 3 let mmap'd read-only vfio regions be able to generate vmexit for > guest write. so, without patch 1, host qemu would crash on guest write to > this read-only region. with patch 1, host qemu would drop the writes. > > Changelog: > v2: > -split one big patches into smaller ones (Philippe) > -modify existing trace to record guest writes to read-only memory (Alex) > -modify vfio_region_write() to drop guest writes to non-mmap'd read-only > region (Alex) > > Yan Zhao (3): > memory: drop guest writes to read-only ram device regions > hw/vfio: drop guest writes to ro regions > hw/vfio: let read-only flag take effect for mmap'd regions > > hw/vfio/common.c | 12 +++++++++++- > hw/vfio/trace-events | 2 +- > memory.c | 6 +++++- > trace-events | 2 +- > 4 files changed, 18 insertions(+), 4 deletions(-) > > -- > 2.17.1 >
On Fri, 3 Apr 2020 at 09:13, Yan Zhao <yan.y.zhao@intel.com> wrote: > > patch 1 modifies handler of ram device memory regions to drop guest writes > to read-only ram device memory regions > > patch 2 modifies handler of non-mmap'd read-only vfio regions to drop guest > writes to those regions > > patch 3 let mmap'd read-only vfio regions be able to generate vmexit for > guest write. so, without patch 1, host qemu would crash on guest write to > this read-only region. with patch 1, host qemu would drop the writes. Just FYI, there seems to be a minor clock or timezone issue with however you're sending these emails: the Date header you sent reads "Date: Fri, 3 Apr 2020 16:56:57 +0000" but that time in the UTC +0000 timezone is (as I write this) still several hours in the future. This isn't a big deal but you probably want to look into fixing it. (Noticed because the wrong-date makes your patches stick to the top of the https://patchew.org/QEMU/ list even after other patches arrive after them.) thanks -- PMM
patch 1 modifies handler of ram device memory regions to drop guest writes to read-only ram device memory regions patch 2 modifies handler of non-mmap'd read-only vfio regions to drop guest writes to those regions patch 3 let mmap'd read-only vfio regions be able to generate vmexit for guest write. so, without patch 1, host qemu would crash on guest write to this read-only region. with patch 1, host qemu would drop the writes. Changelog: v2: -split one big patches into smaller ones (Philippe) -modify existing trace to record guest writes to read-only memory (Alex) -modify vfio_region_write() to drop guest writes to non-mmap'd read-only region (Alex) Yan Zhao (3): memory: drop guest writes to read-only ram device regions hw/vfio: drop guest writes to ro regions hw/vfio: let read-only flag take effect for mmap'd regions hw/vfio/common.c | 12 +++++++++++- hw/vfio/trace-events | 2 +- memory.c | 6 +++++- trace-events | 2 +- 4 files changed, 18 insertions(+), 4 deletions(-)
On Fri, Apr 03, 2020 at 08:53:12PM +0800, Peter Maydell wrote: > On Fri, 3 Apr 2020 at 09:13, Yan Zhao <yan.y.zhao@intel.com> wrote: > > > > patch 1 modifies handler of ram device memory regions to drop guest writes > > to read-only ram device memory regions > > > > patch 2 modifies handler of non-mmap'd read-only vfio regions to drop guest > > writes to those regions > > > > patch 3 let mmap'd read-only vfio regions be able to generate vmexit for > > guest write. so, without patch 1, host qemu would crash on guest write to > > this read-only region. with patch 1, host qemu would drop the writes. > > Just FYI, there seems to be a minor clock or timezone issue with > however you're sending these emails: the Date header you > sent reads "Date: Fri, 3 Apr 2020 16:56:57 +0000" but that > time in the UTC +0000 timezone is (as I write this) still several > hours in the future. This isn't a big deal but you probably want > to look into fixing it. > > (Noticed because the wrong-date makes your patches stick to > the top of the https://patchew.org/QEMU/ list even after other > patches arrive after them.) > thanks for informing of it! will pay attention to it. Thanks Yan