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

Deadcode discussion based on Arm NS phys timer


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Michal Orzel <michal.orzel@xxxxxxx>
  • Date: Mon, 24 Oct 2022 11:07:37 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yccG669GhBoAImAUDk8VGKK0cfD0e+yrcyvnxEv50Dg=; b=WkRMBY1f7YPqbZQ/LddcjzcoDrHGBFqGKq/kIcZcKj6FP4Sy9bm90R5poKdF1A+cy54YyabIsEujEJX4Zd720JsRpwHPWfdVZ/K1kVU6lqgQQXMOLpvR2vQlBbhx9/wV3CSvI4SeVcAClp3iM8E1UTEr3Axh1fbUgwLqMVMRWHM/67HncNCOMe9dI8PFVGUQwXedKAb7uDIsaM8NMZKJieoDmPFT5AOgDajnCau7MQ3r3N0RDJjY6oWUH9nED34GILZI46zqsQvLGo6f++qwn2+WgoC1My9WJSBMTuDgwx0lJ65ieBJvGbXKV5g1PB0CnsWjJCXZrilLhhv/wnKEzQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KmZOscGbt+jv7+pEHaJV3IbGvIHSYmTLIfQT23tLK3+gNDT1+wDUMfhXoKOdQTaRTzwLe20xNLH3EEVQGH6ZAZ+kA/bk8Tmsruv4nVql+Y1x7sBZJ81sKf/IveXGBaACkaBHvb1ZTc1Ylji+QPC1MfG36J/5/A1P4xhiM3mABc1GCxbIcmX5I6nMg8f1W5bqxIb6r0Q4yMTeXoTDduzQ24kTKQgivdWol13tlv9QwGBeLjzpQf3kx6sL+PowtyHwXHGdgYzpJno9ynjdeKVm4DhMJuJSYsc3Hlo4P6jh6zV8K17kIjTBSVXRCz0Oxz/iCOLedo2hpj6xorRot32spg==
  • Cc: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Delivery-date: Mon, 24 Oct 2022 09:07:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hello,

Recently I came across a deadcode in Xen Arm arch timer code. Briefly speaking, 
we are routing
the NS phys timer (CNTP) IRQ to Xen, even though Xen does not make use of it 
(as it uses the hypervisor timer CNTHP).
This timer is fully emulated, which means that there is nothing that can 
trigger such IRQ. This code is
a left over from early days, where the CNTHP was buggy on some models and we 
had to use the CNTP instead.

As far as the problem itself is not really interesting, it raises a question of 
what to do with a deadcode,
as there might be/are other deadcode places in Xen. One may say that it is 
useful to keep it, because one day,
someone might need it when dealing with yet another broken HW. Such person 
would still need to modify the other
part of the code (e.g. reprogram_timer), but there would be less work required 
overall. Personally, I'm not in favor of
such approach, because we should not really support possible scenarios with 
broken HW (except for erratas listing known issues).
Also, as part of the certification/FUSA process, there should be no deadcode 
and we should have explanation for every block of code.

There are different ways to deal with a deadcode:
1. Get rid of it completely
2. Leave it as it is
3. Admit that it can be useful one day and:
  3.1. protect it with #if 0
  3.2. protect it with a new Kconfig option (disabled by default) using #ifdef
  3.3. protect it with a new Kconfig option (disabled by default) using 
IS_ENABLED (to make sure code always compile)
  3.4. protect it with a command line option (allowing to choose the timer to 
be used by Xen)
...

Let me know what you think.

~Michal



 


Rackspace

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