[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC V2 4/6] xen: Support for VMCALL mem_events

  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Tue, 17 Mar 2015 16:33:17 +0200
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, mdontu@xxxxxxxxxxxxxxx, tim@xxxxxxx, xen-devel@xxxxxxxxxxxxx
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 17 Mar 2015 14:31:42 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=vKrehZm0GVAa3NXMQ88w/H5fNmNqoX9i7tdGgpI/Hd6x8HIUwdfn03a418CbtOUeGnvSYRSyj6vrakVjMsqaHgin+6kJvmw6QgaoLMg7VAf1Ep5rY6vbaRXu/Xof27A02k8dHmP+LJVmxNuBFcf+BOCXpvA5HEJspjOR4i8wowVUbNeRSMOg0UcfSinOKLHM/ESLfGpcw1o446DMs+B1njJQfPOWQWzq2eiBGswaFVJCq3GPiIA8DkDQh8GUf6rfsKyPzgWBtpauXIpdCTtgmBClmU/VUKhdqiAuUeDKM+rcOTo0b6DIs0rptA8L9tN/wwbx1N1fm+AZFMTixPdXDA==; h=Received:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-BitDefender-Scanner:X-BitDefender-Spam:X-BitDefender-SpamStamp:X-BitDefender-CF-Stamp;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 03/17/2015 04:20 PM, Jan Beulich wrote:
>>>> On 17.03.15 at 15:07, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> Yes, but Andrew's idea (which I think is very neat) is that instead of
>> the trickery I used to do in the original patch (create a specific
>> VMCALL vm_event and compare eax to a magic constant on VMCALL-based
>> VMEXITS, to figure out if all I wanted to do was send out the event),
>> that I should instead have the guest set up rax, rdi and rsi and execute
>> vmcall, which would then be translated to a real hypercall that sends
>> out a vm_event.
> If you think about a bare HVM guest OS (i.e. without any PV
> drivers), then of course you should provide such hypercall
> wrappers for code to use instead of open coding it in potentially
> many places.
>> In this case, the (HVM) guest does need to concern itself with what
>> registers it should set up for that purpose. I suppose a workaround
>> could be to write the subop in both ebx and rdi, though without any
>> testing I don't know at this point what, if anything, might be broken
>> that way.
> Guest code ought to know what mode it runs in. And introspection
> code (in case this is about injection of such code) ought to also
> know which mode the monitored guest is in.

Yes, we'll try to handle this, I was mainly asking because based on
Andrew's suggestion (which only mentioned rdi, not ebx) I wanted to make
sure that this is not someting that people might prefer to change at Xen
source code level.

Thanks for the clarification,

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.