From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Paul Durrant <paul@xen.org>, Wei Liu <wl@xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/HVM: relinquish resources also from hvm_domain_destroy()
Date: Wed, 29 Jan 2020 10:45:54 +0100 [thread overview]
Message-ID: <320bcfd2-e54e-efa7-e626-fa71aa745df8@suse.com> (raw)
In-Reply-To: <20200129093838.GU57924@desktop-tdan49n.eng.citrite.net>
On 29.01.2020 10:38, Roger Pau Monné wrote:
> On Wed, Jan 29, 2020 at 09:01:34AM +0100, Jan Beulich wrote:
>> On 28.01.2020 18:25, Roger Pau Monné wrote:
>>> On Tue, Jan 28, 2020 at 04:49:09PM +0100, Jan Beulich wrote:
>>>> On 28.01.2020 15:54, Roger Pau Monné wrote:
>>>>> On Tue, Jan 28, 2020 at 02:16:53PM +0100, Jan Beulich wrote:
>>>>>> --- a/xen/arch/x86/hvm/rtc.c
>>>>>> +++ b/xen/arch/x86/hvm/rtc.c
>>>>>> @@ -844,7 +844,8 @@ void rtc_deinit(struct domain *d)
>>>>>> {
>>>>>> RTCState *s = domain_vrtc(d);
>>>>>>
>>>>>> - if ( !has_vrtc(d) )
>>>>>> + if ( !has_vrtc(d) || !d->arch.hvm.pl_time ||
>>>>>> + s->update_timer.status == TIMER_STATUS_invalid )
>>>>>
>>>>> You could also check for the port registration AFAICT, which is maybe
>>>>> more obvious?
>>>>
>>>> You called that approach dirty above - I'd like to restrict it
>>>> to just where no better alternative exists.
>>>
>>> Ack, it didn't seem that bad here because this is a x86 emulated
>>> device that relies on IO ports, while the ioreq code (albeit x86
>>> specific ATM) could be used by other arches, and hence would likely
>>> prefer to avoid using x86 specific details for generic functions, like
>>> the init or deinit ones.
>>
>> Likely, but the port I/O handler registration is going to remain
>> x86-specific, and hence there would pretty certainly also be an
>> arch-specific init (and may a deinit) function.
>>
>>>>> I also wonder whether all those time-related emulations could be
>>>>> grouped into a single helper, that could have a d->arch.hvm.pl_time
>>>>> instead of having to sprinkle such checks for each device?
>>>>
>>>> Quite possible, but not here and not now.
>>>
>>> Sure.
>>>
>>> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>>
>> Thanks. There are two small changes I intend to do, one directly
>> and one indirectly resulting from Paul's feedback: Also drop
>> rtc_deinit() from hvm_domain_destroy(). Also drop now pointless
>> if() from hvm_domain_relinquish_resources().
>
> I assume this is the if condition around the {pmtimer/hpet}_deinit
> calls?
Yes. The other two if()-s obviously can't go away.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
prev parent reply other threads:[~2020-01-29 9:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-28 13:16 [Xen-devel] [PATCH] x86/HVM: relinquish resources also from hvm_domain_destroy() Jan Beulich
2020-01-28 14:14 ` Durrant, Paul
2020-01-28 14:31 ` Jan Beulich
2020-01-28 14:58 ` Durrant, Paul
2020-01-28 14:54 ` Roger Pau Monné
2020-01-28 15:49 ` Jan Beulich
2020-01-28 17:25 ` Roger Pau Monné
2020-01-29 8:01 ` Jan Beulich
2020-01-29 9:38 ` Roger Pau Monné
2020-01-29 9:45 ` Jan Beulich [this message]
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=320bcfd2-e54e-efa7-e626-fa71aa745df8@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--cc=wl@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 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.