From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
eddie.dong@intel.com, xen-devel@lists.xen.org,
jun.nakajima@intel.com, ian.jackson@eu.citrix.com
Subject: Re: [PATCH RFC V4 1/5] xen: Emulate with no writes
Date: Tue, 05 Aug 2014 18:16:26 +0300 [thread overview]
Message-ID: <53E0F54A.6090801@bitdefender.com> (raw)
In-Reply-To: <53DFB0440200007800029111@mail.emea.novell.com>
On 08/04/2014 05:09 PM, Jan Beulich wrote:
>>>> On 04.08.14 at 13:30, <rcojocaru@bitdefender.com> wrote:
>> +static int hvmemul_rep_ins_discard(
>> + uint16_t src_port,
>> + enum x86_segment dst_seg,
>> + unsigned long dst_offset,
>> + unsigned int bytes_per_rep,
>> + unsigned long *reps,
>> + struct x86_emulate_ctxt *ctxt)
>> +{
>> + return X86EMUL_OKAY;
>> +}
>> +
>> +static int hvmemul_rep_movs_discard(
>> + enum x86_segment src_seg,
>> + unsigned long src_offset,
>> + enum x86_segment dst_seg,
>> + unsigned long dst_offset,
>> + unsigned int bytes_per_rep,
>> + unsigned long *reps,
>> + struct x86_emulate_ctxt *ctxt)
>> +{
>> + return X86EMUL_OKAY;
>> +}
>
> ... these don't seem to be: I don't think you can just drop the other
> half of the operation (i.e. the port or MMIO read).
I've been looking at hvmemul_do_io() (in arch/x86/hvm/emulate.c, line
52), which is what the above functions are reduced to. At line 88 I've
come across the following code:
/*
* Weird-sized accesses have undefined behaviour: we discard writes
* and read all-ones.
*/
if ( unlikely((size > sizeof(long)) || (size & (size - 1))) )
{
gdprintk(XENLOG_WARNING, "bad mmio size %d\n", size);
ASSERT(p_data != NULL); /* cannot happen with a REP prefix */
if ( dir == IOREQ_READ )
memset(p_data, ~0, size);
if ( ram_page )
put_page(ram_page);
return X86EMUL_UNHANDLEABLE;
}
which does drop the last half of the function (though it does so by
returning X86EMUL_UNHANDLEABLE). Hvmemul_rep_ins() looks like this:
static int hvmemul_rep_ins(
uint16_t src_port,
enum x86_segment dst_seg,
unsigned long dst_offset,
unsigned int bytes_per_rep,
unsigned long *reps,
struct x86_emulate_ctxt *ctxt)
{
struct hvm_emulate_ctxt *hvmemul_ctxt =
container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
unsigned long addr;
uint32_t pfec = PFEC_page_present | PFEC_write_access;
paddr_t gpa;
p2m_type_t p2mt;
int rc;
rc = hvmemul_virtual_to_linear(
dst_seg, dst_offset, bytes_per_rep, reps, hvm_access_write,
hvmemul_ctxt, &addr);
if ( rc != X86EMUL_OKAY )
return rc;
if ( hvmemul_ctxt->seg_reg[x86_seg_ss].attr.fields.dpl == 3 )
pfec |= PFEC_user_mode;
rc = hvmemul_linear_to_phys(
addr, &gpa, bytes_per_rep, reps, pfec, hvmemul_ctxt);
if ( rc != X86EMUL_OKAY )
return rc;
(void) get_gfn_query_unlocked(current->domain, gpa >> PAGE_SHIFT,
&p2mt);
if ( p2mt == p2m_mmio_direct || p2mt == p2m_mmio_dm )
return X86EMUL_UNHANDLEABLE;
return hvmemul_do_pio(src_port, reps, bytes_per_rep, gpa, IOREQ_READ,
!!(ctxt->regs->eflags & X86_EFLAGS_DF), NULL);
}
So if I understand this code correctly, hvmemul_rep_ins() performs a few
checks, and then calls hvmemul_do_pio(), which ends up calling
hvmemul_do_io(), which seems to discard the write rather unceremoniously
for weird-sized accesses. This would seem to roughly correspond to just
returning X86EMUL_UNHANDLEABLE from hvmemul_rep_ins() for that special
case (with no MMIO code executed).
Did I misunderstand something?
Thanks,
Razvan Cojocaru
next prev parent reply other threads:[~2014-08-05 15:16 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-04 11:30 [PATCH RFC V4 1/5] xen: Emulate with no writes Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 2/5] xen: Optimize introspection access to guest state Razvan Cojocaru
2014-08-04 14:16 ` Jan Beulich
2014-08-04 14:43 ` Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 3/5] xen: Force-enable relevant MSR events; optimize the number of sent MSR events Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 4/5] xen, libxc: Request page fault injection via libxc Razvan Cojocaru
2014-08-04 11:51 ` Ian Campbell
2014-08-04 14:26 ` Jan Beulich
2014-08-04 15:00 ` Razvan Cojocaru
2014-08-04 15:20 ` Jan Beulich
2014-08-05 8:09 ` Razvan Cojocaru
2014-08-05 8:39 ` Jan Beulich
2014-08-05 8:48 ` Razvan Cojocaru
2014-08-05 9:59 ` Razvan Cojocaru
2014-08-04 15:11 ` Razvan Cojocaru
2014-08-04 15:21 ` Jan Beulich
[not found] ` <53DFA537.70105@bitdefender.com>
2014-08-04 15:23 ` Razvan Cojocaru
2014-08-04 11:30 ` [PATCH RFC V4 5/5] xen: Handle resumed instruction based on previous mem_event reply Razvan Cojocaru
2014-08-04 14:33 ` Jan Beulich
2014-08-06 14:00 ` Razvan Cojocaru
2014-08-04 14:09 ` [PATCH RFC V4 1/5] xen: Emulate with no writes Jan Beulich
2014-08-04 14:25 ` Razvan Cojocaru
2014-08-04 14:42 ` Jan Beulich
2014-08-05 15:16 ` Razvan Cojocaru [this message]
2014-08-05 15:27 ` Razvan Cojocaru
2014-08-05 15:43 ` Jan Beulich
2014-08-06 8:42 ` Razvan Cojocaru
2014-08-06 8:50 ` Jan Beulich
2014-08-28 11:53 ` Tim Deegan
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=53E0F54A.6090801@bitdefender.com \
--to=rcojocaru@bitdefender.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=eddie.dong@intel.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.