From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Keir (Xen.org)" <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v5 09/16] x86/hvm: limit reps to avoid the need to handle retry
Date: Thu, 2 Jul 2015 18:31:20 +0100 [thread overview]
Message-ID: <55957568.7070505@citrix.com> (raw)
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025979AB3@AMSPEX01CL02.citrite.net>
On 02/07/15 18:14, Paul Durrant wrote:
>> -----Original Message-----
>> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
>> Sent: 02 July 2015 18:11
>> To: Paul Durrant; xen-devel@lists.xenproject.org
>> Cc: Keir (Xen.org); Jan Beulich
>> Subject: Re: [PATCH v5 09/16] x86/hvm: limit reps to avoid the need to
>> handle retry
>>
>> On 30/06/15 14:05, Paul Durrant wrote:
>>> @@ -235,7 +219,7 @@ static int hvmemul_do_io_buffer(
>>>
>>> BUG_ON(buffer == NULL);
>>>
>>> - rc = hvmemul_do_io(is_mmio, addr, reps, size, dir, df, 0,
>>> + rc = hvmemul_do_io(is_mmio, addr, *reps, size, dir, df, 0,
>>> (uintptr_t)buffer);
>>> if ( rc == X86EMUL_UNHANDLEABLE && dir == IOREQ_READ )
>>> memset(buffer, 0xff, size);
>>> @@ -287,17 +271,53 @@ static int hvmemul_do_io_addr(
>>> bool_t is_mmio, paddr_t addr, unsigned long *reps,
>>> unsigned int size, uint8_t dir, bool_t df, paddr_t ram_gpa)
>>> {
>>> - struct page_info *ram_page;
>>> + struct vcpu *v = current;
>> curr.
>>
>>> + unsigned long ram_gmfn = paddr_to_pfn(ram_gpa);
>> ram_gfn.
>>
>>> + unsigned int page_off = ram_gpa & (PAGE_SIZE - 1);
>> offset and ~PAGE_MASK.
>>
>>> + struct page_info *ram_page[2];
>>> + int nr_pages = 0;
>> unsigned int.
>>
>>> + unsigned long count;
>>> int rc;
>>>
>>> - rc = hvmemul_acquire_page(paddr_to_pfn(ram_gpa), &ram_page);
>>> + rc = hvmemul_acquire_page(ram_gmfn, &ram_page[nr_pages]);
>>> if ( rc != X86EMUL_OKAY )
>>> - return rc;
>>> + goto out;
>>>
>>> - rc = hvmemul_do_io(is_mmio, addr, reps, size, dir, df, 1,
>>> + nr_pages++;
>>> +
>>> + /* Detemine how many reps will fit within this page */
>>> + count = min_t(unsigned long,
>>> + *reps,
>>> + df ?
>>> + (page_off + size - 1) / size :
>>> + (PAGE_SIZE - page_off) / size);
>>> +
>>> + if ( count == 0 )
>>> + {
>>> + /*
>>> + * This access must span two pages, so grab a reference to
>>> + * the next page and do a single rep.
>>> + */
>>> + rc = hvmemul_acquire_page(df ? ram_gmfn - 1 : ram_gmfn + 1,
>>> + &ram_page[nr_pages]);
>> All guest-based ways to trigger an IO spanning a page boundary will be
>> based on linear address. If a guest has paging enabled, this movement
>> to an adjacent physical is not valid. A new pagetable walk will be
>> required to determine the correct second page.
> I don't think that is true. hvmemul_linear_to_phys() will break at non-contiguous boundaries.
Hmm - it looks like it will bail with unhandleable on a straddled access
across a non-contiguous boundary. In which case a comment confirming
the safety of the +/- 1 will be useful to the next person who follows
the same track of logic as I did.
~Andrew
next prev parent reply other threads:[~2015-07-02 17:31 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 13:05 [PATCH v5 00/16] x86/hvm: I/O emulation cleanup and fix Paul Durrant
2015-06-30 13:05 ` [PATCH v5 01/16] x86/hvm: make sure emulation is retried if domain is shutting down Paul Durrant
2015-06-30 13:45 ` Andrew Cooper
2015-06-30 16:14 ` Don Slutz
2015-06-30 16:29 ` Paul Durrant
2015-06-30 13:05 ` [PATCH v5 02/16] x86/hvm: remove multiple open coded 'chunking' loops Paul Durrant
2015-07-02 15:37 ` Andrew Cooper
2015-07-02 15:55 ` Paul Durrant
2015-07-02 16:03 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 03/16] x86/hvm: change hvm_mmio_read_t and hvm_mmio_write_t length argument Paul Durrant
2015-07-02 15:39 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 04/16] x86/hvm: restrict port numbers to uint16_t and sizes to unsigned int Paul Durrant
2015-07-02 15:54 ` Andrew Cooper
2015-07-02 15:56 ` Paul Durrant
2015-06-30 13:05 ` [PATCH v5 05/16] x86/hvm: unify internal portio and mmio intercepts Paul Durrant
2015-07-02 14:52 ` Roger Pau Monné
2015-07-02 15:02 ` Paul Durrant
2015-07-02 15:12 ` Roger Pau Monné
2015-07-02 15:12 ` Paul Durrant
2015-07-02 16:29 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 06/16] x86/hvm: add length to mmio check op Paul Durrant
2015-07-02 16:37 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 07/16] x86/hvm: unify dpci portio intercept with standard portio intercept Paul Durrant
2015-07-02 16:50 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 08/16] x86/hvm: unify stdvga mmio intercept with standard mmio intercept Paul Durrant
2015-07-02 16:55 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 09/16] x86/hvm: limit reps to avoid the need to handle retry Paul Durrant
2015-07-02 17:10 ` Andrew Cooper
2015-07-02 17:14 ` Paul Durrant
2015-07-02 17:31 ` Andrew Cooper [this message]
2015-06-30 13:05 ` [PATCH v5 10/16] x86/hvm: only call hvm_io_assist() from hvm_wait_for_io() Paul Durrant
2015-07-03 15:03 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 11/16] x86/hvm: split I/O completion handling from state model Paul Durrant
2015-07-03 15:08 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 12/16] x86/hvm: remove HVMIO_dispatched I/O state Paul Durrant
2015-07-03 15:12 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 13/16] x86/hvm: remove hvm_io_state enumeration Paul Durrant
2015-07-03 15:13 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 14/16] x86/hvm: use ioreq_t to track in-flight state Paul Durrant
2015-07-03 15:15 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 15/16] x86/hvm: always re-emulate I/O from a buffer Paul Durrant
2015-07-03 15:26 ` Andrew Cooper
2015-06-30 13:05 ` [PATCH v5 16/16] x86/hvm: track large memory mapped accesses by buffer offset Paul Durrant
2015-07-03 15:26 ` Andrew Cooper
2015-06-30 14:48 ` [PATCH v5 00/16] x86/hvm: I/O emulation cleanup and fix Fabio Fantoni
2015-07-07 11:19 ` Fabio Fantoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55957568.7070505@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).