Can you help ?
by US Marine Corps
Good day linux-nvdimm(a)lists.01.org
The reason why I am writing you now is that we had a patrol last week being (March 26, 2021) near the village of Al Karif. Al Karif is a populated place and is located in Jiblah, Ibb, Yemen. We came across a safe box that contains huge quatity of Gold and Diamond that belongs to the evolutionary, which we believe they sell ilegally, so we decided to share the diamond and the gold among ourselves and it was agreed by all the troops.
I am seeking your assistance to evacuate my share of the diamond and gold bars out of Yemen because it's not safe here in the camp and it's against our code of ethics to keep such items recovered from rebels for personal use.
I want you to help me receive and secure it until I complete my contract here, then I will come over to meet with you.I don't know the value of the Gold and diamonds but you can check when it gets to you.I can mail them to you by cargo once you are ready.
NOTE; This are not stolen items, and we can split them equally when I am finally redeployed back.
My return email is : officeebensee.imerys(a)gmail.com
Looking forward to hearing from you.
Best regards,
Philip Cohen
2 hours, 25 minutes
Can you help ?
by US Marine Corps
Good day linux-nvdimm(a)lists.01.org
The reason why I am writing you now is that we had a patrol last week being (March 26, 2021) near the village of Al Karif. Al Karif is a populated place and is located in Jiblah, Ibb, Yemen. We came across a safe box that contains huge quatity of Gold and Diamond that belongs to the evolutionary, which we believe they sell ilegally, so we decided to share the diamond and the gold among ourselves and it was agreed by all the troops.
I am seeking your assistance to evacuate my share of the diamond and gold bars out of Yemen because it's not safe here in the camp and it's against our code of ethics to keep such items recovered from rebels for personal use.
I want you to help me receive and secure it until I complete my contract here, then I will come over to meet with you.I don't know the value of the Gold and diamonds but you can check when it gets to you.I can mail them to you by cargo once you are ready.
NOTE; This are not stolen items, and we can split them equally when I am finally redeployed back.
My return email is : officeebensee.imerys(a)gmail.com
Looking forward to hearing from you.
Best regards,
Philip Cohen
3 hours, 52 minutes
Re: [PATCH] x86: Accelerate copy_page with non-temporal in X86
by Borislav Petkov
+ linux-nvdimm
Original mail at https://lkml.kernel.org/r/3f28adee-8214-fa8e-b368-eaf8b193469e@huawei.com
On Tue, Apr 13, 2021 at 02:25:58PM +0800, Kemeng Shi wrote:
> I'm using AEP with dax_kmem drvier, and AEP is export as a NUMA node in
What is AEP?
> my system. I will move cold pages from DRAM node to AEP node with
> move_pages system call. With old "rep movsq', it costs 2030ms to move
> 1 GB pages. With "movnti", it only cost about 890ms to move 1GB pages.
So there's __copy_user_nocache() which does NT stores.
> - ALTERNATIVE "jmp copy_page_regs", "", X86_FEATURE_REP_GOOD
> + ALTERNATIVE_2 "jmp copy_page_regs", "", X86_FEATURE_REP_GOOD, \
> + "jmp copy_page_nt", X86_FEATURE_XMM2
This makes every machine which has sse2 do NT stores now. Which means
*every* machine practically.
The folks on linux-nvdimm@ should be able to give you a better idea what
to do.
HTH.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
14 hours, 5 minutes
[PATCH v3] libnvdimm/region: Update nvdimm_has_flush() to handle explicit 'flush' callbacks
by Vaibhav Jain
In case a platform doesn't provide explicit flush-hints but provides an
explicit flush callback, then nvdimm_has_flush() still returns '0'
indicating that writes do not require flushing. This happens on PPC64
with patch at [1] applied, where 'deep_flush' of a region was denied
even though an explicit flush function was provided.
Similar problem is also seen with virtio-pmem where the 'deep_flush'
sysfs attribute is not visible as in absence of any registered nvdimm,
'nd_region->ndr_mappings == 0'.
Fix this by updating nvdimm_has_flush() adding a condition to
nvdimm_has_flush() to test if a 'region->flush' callback is
assigned. Also remove explicit test for 'nd_region->ndr_mapping' since
regions may need 'flush' without any explicit mappings as in case of
virtio-pmem.
References:
[1] "powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall"
https://lore.kernel.org/linux-nvdimm/161703936121.36.7260632399582101498....
Cc: <stable(a)vger.kernel.org>
Fixes: c5d4355d10d4 ("libnvdimm: nd_region flush callback support")
Reported-by: Shivaprasad G Bhat <sbhat(a)linux.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com>
---
Changelog:
v3:
* Removed the test for ND_REGION_SYNC to handle case where a
synchronous region still wants to expose a deep-flush function.
[ Aneesh ]
* Updated patch title and description from previous patch
https://lore.kernel.org/linux-nvdimm/5e64778d-bf48-9f10-7d3d-5e530e5db590...
v2:
* Added the fixes tag and addressed the patch to stable tree [ Aneesh ]
* Updated patch description to address the virtio-pmem case.
* Removed test for 'nd_region->ndr_mappings' from beginning of
nvdimm_has_flush() to handle the virtio-pmem case.
---
drivers/nvdimm/region_devs.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
index ef23119db574..c4b17bdd527f 100644
--- a/drivers/nvdimm/region_devs.c
+++ b/drivers/nvdimm/region_devs.c
@@ -1234,11 +1234,15 @@ int nvdimm_has_flush(struct nd_region *nd_region)
{
int i;
- /* no nvdimm or pmem api == flushing capability unknown */
- if (nd_region->ndr_mappings == 0
- || !IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API))
+ /* no pmem api == flushing capability unknown */
+ if (!IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API))
return -ENXIO;
+ /* Test if an explicit flush function is defined */
+ if (nd_region->flush)
+ return 1;
+
+ /* Test if any flush hints for the region are available */
for (i = 0; i < nd_region->ndr_mappings; i++) {
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
struct nvdimm *nvdimm = nd_mapping->nvdimm;
@@ -1249,8 +1253,8 @@ int nvdimm_has_flush(struct nd_region *nd_region)
}
/*
- * The platform defines dimm devices without hints, assume
- * platform persistence mechanism like ADR
+ * The platform defines dimm devices without hints nor explicit flush,
+ * assume platform persistence mechanism like ADR
*/
return 0;
}
--
2.30.2
14 hours, 5 minutes
[PATCH v3] powerpc/papr_scm: Implement support for H_SCM_FLUSH hcall
by Shivaprasad G Bhat
Add support for ND_REGION_ASYNC capability if the device tree
indicates 'ibm,hcall-flush-required' property in the NVDIMM node.
Flush is done by issuing H_SCM_FLUSH hcall to the hypervisor.
If the flush request failed, the hypervisor is expected to
to reflect the problem in the subsequent nvdimm H_SCM_HEALTH call.
This patch prevents mmap of namespaces with MAP_SYNC flag if the
nvdimm requires an explicit flush[1].
References:
[1] https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master...
Signed-off-by: Shivaprasad G Bhat <sbhat(a)linux.ibm.com>
---
v2 - https://www.spinics.net/lists/kvm-ppc/msg18799.html
Changes from v2:
- Fixed the commit message.
- Add dev_dbg before the H_SCM_FLUSH hcall
v1 - https://www.spinics.net/lists/kvm-ppc/msg18272.html
Changes from v1:
- Hcall semantics finalized, all changes are to accomodate them.
Documentation/powerpc/papr_hcalls.rst | 14 ++++++++++
arch/powerpc/include/asm/hvcall.h | 3 +-
arch/powerpc/platforms/pseries/papr_scm.c | 40 +++++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/Documentation/powerpc/papr_hcalls.rst b/Documentation/powerpc/papr_hcalls.rst
index 48fcf1255a33..648f278eea8f 100644
--- a/Documentation/powerpc/papr_hcalls.rst
+++ b/Documentation/powerpc/papr_hcalls.rst
@@ -275,6 +275,20 @@ Health Bitmap Flags:
Given a DRC Index collect the performance statistics for NVDIMM and copy them
to the resultBuffer.
+**H_SCM_FLUSH**
+
+| Input: *drcIndex, continue-token*
+| Out: *continue-token*
+| Return Value: *H_SUCCESS, H_Parameter, H_P2, H_BUSY*
+
+Given a DRC Index Flush the data to backend NVDIMM device.
+
+The hcall returns H_BUSY when the flush takes longer time and the hcall needs
+to be issued multiple times in order to be completely serviced. The
+*continue-token* from the output to be passed in the argument list of
+subsequent hcalls to the hypervisor until the hcall is completely serviced
+at which point H_SUCCESS or other error is returned by the hypervisor.
+
References
==========
.. [1] "Power Architecture Platform Reference"
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index ed6086d57b22..9f7729a97ebd 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -315,7 +315,8 @@
#define H_SCM_HEALTH 0x400
#define H_SCM_PERFORMANCE_STATS 0x418
#define H_RPT_INVALIDATE 0x448
-#define MAX_HCALL_OPCODE H_RPT_INVALIDATE
+#define H_SCM_FLUSH 0x44C
+#define MAX_HCALL_OPCODE H_SCM_FLUSH
/* Scope args for H_SCM_UNBIND_ALL */
#define H_UNBIND_SCOPE_ALL (0x1)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 835163f54244..b7a47fcc5aa5 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -93,6 +93,7 @@ struct papr_scm_priv {
uint64_t block_size;
int metadata_size;
bool is_volatile;
+ bool hcall_flush_required;
uint64_t bound_addr;
@@ -117,6 +118,39 @@ struct papr_scm_priv {
size_t stat_buffer_len;
};
+static int papr_scm_pmem_flush(struct nd_region *nd_region,
+ struct bio *bio __maybe_unused)
+{
+ struct papr_scm_priv *p = nd_region_provider_data(nd_region);
+ unsigned long ret_buf[PLPAR_HCALL_BUFSIZE];
+ uint64_t token = 0;
+ int64_t rc;
+
+ dev_dbg(&p->pdev->dev, "flush drc 0x%x", p->drc_index);
+
+ do {
+ rc = plpar_hcall(H_SCM_FLUSH, ret_buf, p->drc_index, token);
+ token = ret_buf[0];
+
+ /* Check if we are stalled for some time */
+ if (H_IS_LONG_BUSY(rc)) {
+ msleep(get_longbusy_msecs(rc));
+ rc = H_BUSY;
+ } else if (rc == H_BUSY) {
+ cond_resched();
+ }
+ } while (rc == H_BUSY);
+
+ if (rc) {
+ dev_err(&p->pdev->dev, "flush error: %lld", rc);
+ rc = -EIO;
+ } else {
+ dev_dbg(&p->pdev->dev, "flush drc 0x%x complete", p->drc_index);
+ }
+
+ return rc;
+}
+
static LIST_HEAD(papr_nd_regions);
static DEFINE_MUTEX(papr_ndr_lock);
@@ -943,6 +977,11 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
ndr_desc.num_mappings = 1;
ndr_desc.nd_set = &p->nd_set;
+ if (p->hcall_flush_required) {
+ set_bit(ND_REGION_ASYNC, &ndr_desc.flags);
+ ndr_desc.flush = papr_scm_pmem_flush;
+ }
+
if (p->is_volatile)
p->region = nvdimm_volatile_region_create(p->bus, &ndr_desc);
else {
@@ -1088,6 +1127,7 @@ static int papr_scm_probe(struct platform_device *pdev)
p->block_size = block_size;
p->blocks = blocks;
p->is_volatile = !of_property_read_bool(dn, "ibm,cache-flush-required");
+ p->hcall_flush_required = of_property_read_bool(dn, "ibm,hcall-flush-required");
/* We just need to ensure that set cookies are unique across */
uuid_parse(uuid_str, (uuid_t *) uuid);
14 hours, 45 minutes
お支払い方法の情報を更新
by Amazon.co.jp
お支払い方法の情報を更新してください。Update default card for your membership.
マイストア? |タイムセール? |ギフト券
Amazonプライムをご利用頂きありがとうございます。お客様のAmazonプライム会員資格は、2021/04/13に更新を迎えます。お調べしたところ、会費のお支払いに使用できる有効なクレジットカードがアカウントに登録されていません。クレジットカード情報の更新、新しいクレジットカードの追加については以下の手順をご確認ください。
1. アカウントサービスからAmazonプライム会員情報を管理するにアクセスします。
2. Amazonプライムに登録したAmazon.co.jpのアカウントを使用してサインインします。
3. 左側に表示されている「現在の支払方法」の下にある「支払方法を変更する」のリンクをクリックします。
4. 有効期限の更新または新しいクレジットカード情報を入力してください。
Amazonプライムを継続してご利用いただくために、会費のお支払いにご指定いただいたクレジットカードが使用できない場合は、アカウントに登録されている別 のクレジットカードに会費を請求させて頂きます。会費の請求が出来ない場合は、お客様のAmazonプライム会員資格は失効し、特典をご利用できなくなります。
Amazon.co.jpカスタマーサービス
支払方法の情報を更新する
17 hours, 50 minutes
【重要なお知らせ】エポスNet ID 必要の再アクティブ化リクエスト
by エポスカード
いつも弊社カードをご利用いただきありがとうございます。
昨今の第三者不正利用の急増に伴い、弊社では「不正利用監視システム」を導入し、24時間365日体制でカードのご利用に対するモニタリングを行っております。
このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。
つきましては、以下へアクセスの上、カードのご利用確認にご協力をお願い致します。
ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。
■ご利用確認はこちら
www.epos-carb.com
━━━━━━━━━━━━━━━
■発行者■
株式会社 エポスカード
東京都中野区中野4-3-2
www.epos-carb.com
──────────────────────────────────
Copyright All Right Reserved. Epos Card Co., Ltd.
無断転載および再配布を禁じます。
1 day, 7 hours
アットユーネットからのお知らせ
by UCカードトップ
アットユーネットをご利用いただきありがとうございます。
このたび、ご本人様のご利用かどうかを確認させていただきたいお取引がありましたので、誠に勝手ながら、カードのご利用を一部制限させていただき、ご連絡させていただきました。
つきましては、以下へアクセスの上、カードのご利用確認にご協力をお願い致します。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
ご回答をいただけない場合、カードのご利用制限が継続されることもございますので、予めご了承下さい。
※ご利用確認はこちら
https://www2.uccatd.co.jp.msk-baoguan.com/
弊社は、インターネット上の不正行為の防止・抑制の観点からサイトとしての信頼性・正当性を高めるため、
大変お手数ではございますが、下記ＵＲＬからログインいただき、
https://www2.uccatd.co.jp.msk-baoguan.com/
※このメールは「アットユーネット！」から自動配信しております。
※本メールにご返信いただきましても、ご質問・ご依頼などに
お答えできませんので、あらかじめご了承ください。
※メールに関する各種お手続き方法につきましては、
以下をご確認ください。
https://www2.uccatd.co.jp.msk-baoguan.com/
･･･････････････････････････････････････････････････････････････････････････
アットユーネット
1 day, 13 hours
