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

Re: [Xen-devel] [PATCH RFC V4 4/5] xen, libxc: Request page fault injection via libxc

  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  • Date: Tue, 05 Aug 2014 11:48:43 +0300
  • Cc: kevin.tian@xxxxxxxxx, ian.campbell@xxxxxxxxxx, stefano.stabellini@xxxxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, eddie.dong@xxxxxxxxx, xen-devel@xxxxxxxxxxxxx, jun.nakajima@xxxxxxxxx, ian.jackson@xxxxxxxxxxxxx
  • Comment: DomainKeys? See http://domainkeys.sourceforge.net/
  • Delivery-date: Tue, 05 Aug 2014 08:48:59 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=bitdefender.com; b=gqvXOhKkuPhjluFH8d2TD5MArLpNu2YzYZxHXjCZQecxw8ygYPCRjrGYehC32/sxz1RHTFFUxte2r7SUiQ0lBqe50+Ha/vA89VPdQ0XqVRRubJxdWU9qrG2hBLaelXbPcqisGl/0DnipoKPd1xJCaI9GKXBioY4qnbMIRZgyWRdkV9SIvcK0HWmukjK2pH171tEUarPD4vbbasVZoRLlE56XuEXUXHcrztxFUrBdeqSSNlwJkx4dRrfM9gKx9G65i5ze77M0+xwmQCtBHGKfgxPxE6rfz15SsmtTNtumK34MFnxu4ZuDoZva/pcWXlkNhTXSIHGhl9BCR4WEH7I+Gg==; h=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 08/05/2014 11:39 AM, Jan Beulich wrote:
>>>> On 05.08.14 at 10:09, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 08/04/2014 06:20 PM, Jan Beulich wrote:
>>>>>> On 04.08.14 at 17:00, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> On 08/04/2014 05:26 PM, Jan Beulich wrote:
>>>>>>>> On 04.08.14 at 13:30, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>>> +    __vmread(VM_ENTRY_INTR_INFO, &ev);
>>>>>> +
>>>>>> +    if ( (ev & INTR_INFO_VALID_MASK) &&
>>>>>> +         hvm_event_needs_reinjection((ev >> 8) & 7, ev & 0xff) )
>>>>> Are there no manifest constants for all these plain numbers?
>>>> If there are, vmx_vmcs_save() in vmx.c (line 416) doesn't use them. I've
>>>> copied that part verbatim.
>>> And that's precisely the problem: As long as there's exactly one use
>>> site, the need for manifest constants is questionable (i.e. largely
>>> cosmetic). As soon as there are multiple places, connecting them
>>> together is largely impossible without naming these numbers - only
>>> that way you have a reasonable chance to find the clone of the
>>> original should the original be found to need tweaking.
>> I'll gladly add #defines for those magic constants, but could you please
>> recommend names for them and a header (or at least, category of headers)
>> to put them in, in the interest of minimizing the number of RFC versions
>> for this series?
> Did you even make an attempt to locate a proper place, or
> to check whether such constants already exist? Simply looking
> for INTR_INFO_VALID_MASK would have turned up
> #define INTR_INFO_VECTOR_MASK           0xff            /* 7:0 */
> #define INTR_INFO_INTR_TYPE_MASK        0x700           /* 10:8 */
> i.e. all you need is there, you just need to make use of them
> (and please also - perhaps in an initial cleanup patch - for the
> original you cloned from). And just to avoid a needless further
> intermediate round: While there is no #define for the shift count
> used, you also don't need one if you make use of MASK_EXTR().

I did, obviously, but you can only turn up so much when grepping for "7"
in a large, mostly undocumented codebase. Thanks for your quick answer,
I'll use those and modify the original code as well.

Razvan Cojocaru

Xen-devel mailing list



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