From gerbra at gotadsl.co.uk Mon Jan 1 04:49:16 2018 From: gerbra at gotadsl.co.uk (Pkg-xen-devel) Date: Mon, 1 Jan 2018 02:49:16 -0200 Subject: [Pkg-xen-devel] =?utf-8?q?=E2=9C=88Merry_Christmas_to_All_and_to_?= =?utf-8?q?All_a_Good_Flight?= Message-ID: <00106327825a$fe860960$9f98951a$@gotadsl.co.uk> Flight Coupons, Promo Codes & Deals - Dec 2017 Top Deal 55% Off: Christmas Flight Deals and New Year Flight Deals. Call to Us and Get Discount Now (888) 369-2751. (24/7 Support.)

Enjoy Christmas Deals on American Airlines, Delta Air Lines, Southwest Airlines, United Airlines, Air Canada, JetBlue, Alaska Airlines, WestJet, Aeromexico, Spirit Airlines, Frontier Airlines, Volaris, Hawaiian Airlines, Allegiant Air, Virgin America. Don't Miss These Handpicked Fares
Chicago-New York$175.95
Los Angeles-San Francisco$103.67
Los Angeles-New York$175.50
Chicago-Los Angeles$325.65
Miami-New York$96.68
Atlanta-Chicago$100.69
Newark-Toronto$299.80
New York City-Las Vegas$248.89
New York City-Kingston$461.60
Los Angeles-Manila$654.78
San Francisco-Tokyo$690.83
New York City-Casablanca$825.49
Miami-Johannesburg$1016.03
Call to Us and Get Discount Now (888) 369-2751. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner at bugs.debian.org Sat Jan 6 15:15:05 2018 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sat, 06 Jan 2018 15:15:05 +0000 Subject: [Pkg-xen-devel] Processed: Re: Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 References: <1515251501.3305.29.camel@debian.org> Message-ID: Processing control commands: > reassign -1 xen-hypervisor-4.8-amd64 Bug #880554 [linux-image-4.9.0-4-amd64] xen domu freezes with kernel linux-image-4.9.0-4-amd64 Bug reassigned from package 'linux-image-4.9.0-4-amd64' to 'xen-hypervisor-4.8-amd64'. No longer marked as found in versions linux/4.9.51-1. Ignoring request to alter fixed versions of bug #880554 to the same values previously set -- 880554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880554 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From corsac at debian.org Sat Jan 6 15:11:41 2018 From: corsac at debian.org (Yves-Alexis Perez) Date: Sat, 06 Jan 2018 16:11:41 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <20180106142356.GA6604@gavran.carpriv.carnet.hr> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> Message-ID: <1515251501.3305.29.camel@debian.org> control: reassign -1 xen-hypervisor-4.8-amd64 On Sat, 2018-01-06 at 15:23 +0100, Valentin Vidic wrote: > On Sat, Jan 06, 2018 at 03:08:26PM +0100, Yves-Alexis Perez wrote: > > According to that link, the fix seems to be configuration rather than > > code. > > Does this mean this bug against the kernel should be closed? > > Yes, the problem seems to be in the Xen hypervisor and not the Linux > kernel itself. The default value for the gnttab_max_frames parameter > needs to be increased to avoid domU disk IO hangs, for example: > > GRUB_CMDLINE_XEN="dom0_mem=10240M gnttab_max_frames=256" > > So either close the bug or reassign it to xen-hypervisor package so > they can increase the default value for this parameter in the > hypervisor code. > Ok, I'll reassign and let the Xen maintainers handle that (maybe in a stable update). @Xen maintainers: see the complete bug log for more information, but basically it seems that a domu freezes happens with the ?new? multi-queue xen blk driver, and the fix is to increase a configuration value. Valentin suggests adding that to the default. Regards, -- Yves-Alexis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From hans at knorrie.org Sat Jan 6 22:17:00 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Sat, 6 Jan 2018 23:17:00 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <1515251501.3305.29.camel@debian.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> Message-ID: <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> Hi Christian and everyone else, Ack on reassign to Xen. On 01/06/2018 04:11 PM, Yves-Alexis Perez wrote: > control: reassign -1 xen-hypervisor-4.8-amd64 > > On Sat, 2018-01-06 at 15:23 +0100, Valentin Vidic wrote: >> On Sat, Jan 06, 2018 at 03:08:26PM +0100, Yves-Alexis Perez wrote: >>> According to that link, the fix seems to be configuration rather than >>> code. >>> Does this mean this bug against the kernel should be closed? >> >> Yes, the problem seems to be in the Xen hypervisor and not the Linux >> kernel itself. The default value for the gnttab_max_frames parameter >> needs to be increased to avoid domU disk IO hangs, for example: >> >> GRUB_CMDLINE_XEN="dom0_mem=10240M gnttab_max_frames=256" >> >> So either close the bug or reassign it to xen-hypervisor package so >> they can increase the default value for this parameter in the >> hypervisor code. >> > Ok, I'll reassign and let the Xen maintainers handle that (maybe in a stable > update). > > @Xen maintainers: see the complete bug log for more information, but basically > it seems that a domu freezes happens with the ?new? multi-queue xen blk > driver, and the fix is to increase a configuration value. Valentin suggests > adding that to the default. The dom0 gnttab_max_frames boot setting is about how many pages are allocated to fill with 'grants'. The grant concept is related to sharing information between the dom0 and domU. It allows memory pages to be shared back and forth, so that e.g. a domU can fill a page with outgoing network packets or disk writes. Then the dom0 can take over ownership of the memory page and read the contents and do its trick with it. In this way, zero-copy IO is implemented. When running xen domUs, the total amount of network interfaces and block devices that are attached to all of the domUs that are running (and, apparently, how heavy they are used) cause the usage of these grant guys to increase. At some point you run out of grants because all of the pages are filled. I agree that the upstream default, 32 is quite low. This is indeed a configuration issue. I myself ran into this years ago with a growing number of domUs and network interfaces in use. We have been using gnttab_max_nr_frames=128 for a long time already instead. I was tempted to reassign src:xen, but in the meantime, this option has already been removed again, so this bug does not apply to unstable (well, as soon as we get something new in there) any more (as far as I can see quickly now). https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=18b1be5e324bcbe2f10898b116db641d404b3d30 Including a better default for gnttab_max_nr_frames in the grub config in the debian xen package in stable sounds reasonable from a best practices point of view. But, I would be interested in learning more about the relation with block mq although. Does using newer linux kernels (like from stretch-backports) for the domU always put a bigger strain on this? Or, is it just related to the overall number of network devices and block devices you are adding to your domUs in your specific own situation, and did you just trip over the default limit? In any case, the grub option thing is a conffile, so any user upgrading has to accept/merge the change, so we won't cause a stable user to just run out of memory because of a few extra kilobytes of memory usage without notice. Hans van Kranenburg P.S. Debian Xen team is in the process of being "rebooted" while the current shitstorm about meltdown/spectre is going on, so don't hold your breath. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hans at knorrie.org Sat Jan 6 22:17:00 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Sat, 6 Jan 2018 23:17:00 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <1515251501.3305.29.camel@debian.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> Message-ID: <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> Hi Christian and everyone else, Ack on reassign to Xen. On 01/06/2018 04:11 PM, Yves-Alexis Perez wrote: > control: reassign -1 xen-hypervisor-4.8-amd64 > > On Sat, 2018-01-06 at 15:23 +0100, Valentin Vidic wrote: >> On Sat, Jan 06, 2018 at 03:08:26PM +0100, Yves-Alexis Perez wrote: >>> According to that link, the fix seems to be configuration rather than >>> code. >>> Does this mean this bug against the kernel should be closed? >> >> Yes, the problem seems to be in the Xen hypervisor and not the Linux >> kernel itself. The default value for the gnttab_max_frames parameter >> needs to be increased to avoid domU disk IO hangs, for example: >> >> GRUB_CMDLINE_XEN="dom0_mem=10240M gnttab_max_frames=256" >> >> So either close the bug or reassign it to xen-hypervisor package so >> they can increase the default value for this parameter in the >> hypervisor code. >> > Ok, I'll reassign and let the Xen maintainers handle that (maybe in a stable > update). > > @Xen maintainers: see the complete bug log for more information, but basically > it seems that a domu freezes happens with the ?new? multi-queue xen blk > driver, and the fix is to increase a configuration value. Valentin suggests > adding that to the default. The dom0 gnttab_max_frames boot setting is about how many pages are allocated to fill with 'grants'. The grant concept is related to sharing information between the dom0 and domU. It allows memory pages to be shared back and forth, so that e.g. a domU can fill a page with outgoing network packets or disk writes. Then the dom0 can take over ownership of the memory page and read the contents and do its trick with it. In this way, zero-copy IO is implemented. When running xen domUs, the total amount of network interfaces and block devices that are attached to all of the domUs that are running (and, apparently, how heavy they are used) cause the usage of these grant guys to increase. At some point you run out of grants because all of the pages are filled. I agree that the upstream default, 32 is quite low. This is indeed a configuration issue. I myself ran into this years ago with a growing number of domUs and network interfaces in use. We have been using gnttab_max_nr_frames=128 for a long time already instead. I was tempted to reassign src:xen, but in the meantime, this option has already been removed again, so this bug does not apply to unstable (well, as soon as we get something new in there) any more (as far as I can see quickly now). https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=18b1be5e324bcbe2f10898b116db641d404b3d30 Including a better default for gnttab_max_nr_frames in the grub config in the debian xen package in stable sounds reasonable from a best practices point of view. But, I would be interested in learning more about the relation with block mq although. Does using newer linux kernels (like from stretch-backports) for the domU always put a bigger strain on this? Or, is it just related to the overall number of network devices and block devices you are adding to your domUs in your specific own situation, and did you just trip over the default limit? In any case, the grub option thing is a conffile, so any user upgrading has to accept/merge the change, so we won't cause a stable user to just run out of memory because of a few extra kilobytes of memory usage without notice. Hans van Kranenburg P.S. Debian Xen team is in the process of being "rebooted" while the current shitstorm about meltdown/spectre is going on, so don't hold your breath. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From Valentin.Vidic at CARNet.hr Sun Jan 7 09:05:07 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Sun, 7 Jan 2018 10:05:07 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> Message-ID: <20180107090507.GC6604@gavran.carpriv.carnet.hr> On Sat, Jan 06, 2018 at 11:17:00PM +0100, Hans van Kranenburg wrote: > I agree that the upstream default, 32 is quite low. This is indeed a > configuration issue. I myself ran into this years ago with a growing > number of domUs and network interfaces in use. We have been using > gnttab_max_nr_frames=128 for a long time already instead. > > I was tempted to reassign src:xen, but in the meantime, this option has > already been removed again, so this bug does not apply to unstable > (well, as soon as we get something new in there) any more (as far as I > can see quickly now). > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=18b1be5e324bcbe2f10898b116db641d404b3d30 It does not seem to be removed but increased the default from 32 to 64? > Including a better default for gnttab_max_nr_frames in the grub config > in the debian xen package in stable sounds reasonable from a best > practices point of view. > > But, I would be interested in learning more about the relation with > block mq although. Does using newer linux kernels (like from > stretch-backports) for the domU always put a bigger strain on this? Or, > is it just related to the overall number of network devices and block > devices you are adding to your domUs in your specific own situation, and > did you just trip over the default limit? After upgrading the domU and dom0 from jessie to stretch on a big postgresql database server (50 VCPUs, 200GB RAM) it starting freezing very soon after boot as posted there here: https://lists.xen.org/archives/html/xen-users/2017-07/msg00057.html It did not have these problems while running jessie versions of the hypervisor and the kernels. The problem seems to be related to the number of CPUs used, as smaller domUs with a few VCPUs did not hang like this. Could it be that large number of VCPUs -> more queues in Xen mq driver -> faster exhaustion of allocated pages? -- Valentin From Valentin.Vidic at CARNet.hr Sun Jan 7 09:05:07 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Sun, 7 Jan 2018 10:05:07 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> Message-ID: <20180107090507.GC6604@gavran.carpriv.carnet.hr> On Sat, Jan 06, 2018 at 11:17:00PM +0100, Hans van Kranenburg wrote: > I agree that the upstream default, 32 is quite low. This is indeed a > configuration issue. I myself ran into this years ago with a growing > number of domUs and network interfaces in use. We have been using > gnttab_max_nr_frames=128 for a long time already instead. > > I was tempted to reassign src:xen, but in the meantime, this option has > already been removed again, so this bug does not apply to unstable > (well, as soon as we get something new in there) any more (as far as I > can see quickly now). > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=18b1be5e324bcbe2f10898b116db641d404b3d30 It does not seem to be removed but increased the default from 32 to 64? > Including a better default for gnttab_max_nr_frames in the grub config > in the debian xen package in stable sounds reasonable from a best > practices point of view. > > But, I would be interested in learning more about the relation with > block mq although. Does using newer linux kernels (like from > stretch-backports) for the domU always put a bigger strain on this? Or, > is it just related to the overall number of network devices and block > devices you are adding to your domUs in your specific own situation, and > did you just trip over the default limit? After upgrading the domU and dom0 from jessie to stretch on a big postgresql database server (50 VCPUs, 200GB RAM) it starting freezing very soon after boot as posted there here: https://lists.xen.org/archives/html/xen-users/2017-07/msg00057.html It did not have these problems while running jessie versions of the hypervisor and the kernels. The problem seems to be related to the number of CPUs used, as smaller domUs with a few VCPUs did not hang like this. Could it be that large number of VCPUs -> more queues in Xen mq driver -> faster exhaustion of allocated pages? -- Valentin From hans at knorrie.org Sun Jan 7 18:36:40 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Sun, 7 Jan 2018 19:36:40 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <20180107090507.GC6604@gavran.carpriv.carnet.hr> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> Message-ID: <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> On 01/07/2018 10:05 AM, Valentin Vidic wrote: > On Sat, Jan 06, 2018 at 11:17:00PM +0100, Hans van Kranenburg wrote: >> I agree that the upstream default, 32 is quite low. This is indeed a >> configuration issue. I myself ran into this years ago with a growing >> number of domUs and network interfaces in use. We have been using >> gnttab_max_nr_frames=128 for a long time already instead. >> >> I was tempted to reassign src:xen, but in the meantime, this option has >> already been removed again, so this bug does not apply to unstable >> (well, as soon as we get something new in there) any more (as far as I >> can see quickly now). >> >> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=18b1be5e324bcbe2f10898b116db641d404b3d30 > > It does not seem to be removed but increased the default from 32 to 64? Ehm, yes you are correct. I was misreading and mixing up things. Let's try again... The referenced commit is talking about removal of the obsolete gnttab_max_nr_frames from the documentation, so not related. >> Including a better default for gnttab_max_nr_frames in the grub config >> in the debian xen package in stable sounds reasonable from a best >> practices point of view. So, that's gnttab_max_frames, not gnttab_max_nr_frames... I was reading out loud from my old Jessie dom0 grub config. >> But, I would be interested in learning more about the relation with >> block mq although. Does using newer linux kernels (like from >> stretch-backports) for the domU always put a bigger strain on this? Or, >> is it just related to the overall number of network devices and block >> devices you are adding to your domUs in your specific own situation, and >> did you just trip over the default limit? > > After upgrading the domU and dom0 from jessie to stretch on a big postgresql > database server (50 VCPUs, 200GB RAM) it starting freezing very soon > after boot as posted there here: > > https://lists.xen.org/archives/html/xen-users/2017-07/msg00057.html > > It did not have these problems while running jessie versions of the > hypervisor and the kernels. The problem seems to be related to the > number of CPUs used, as smaller domUs with a few VCPUs did not hang > like this. Could it be that large number of VCPUs -> more queues in > Xen mq driver -> faster exhaustion of allocated pages? That exactly seems to be the case yes. Maybe this is also one of the reasons that the default max was increased in Xen. "xen/blkback: make pool of persistent grants and free pages per-queue" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4bf0065b7251afb723a29b2fd58f7c38f8ce297 Recently a tool was added to "dump guest grant table info". You could see if it compiles on the 4.8 source and see if it works? Would be interesting to get some idea about how high or low these numbers are in different scenarios. I mean, I'm using 128, you 256, and we even don't know if the actual value is maybe just above 32? :] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=df36d82e3fc91bee2ff1681fd438c815fa324b6a If this is something users are going to run into while not doing more unusual things like having dozens of vcpus or network interfaces, then changing the default could prevent hours of frustration and debugging for them. The least invasive option is to add the option to the documentation of GRUB_CMDLINE_XEN_DEFAULT in /etc/default/grub.d/xen.cfg like "If you have more than xyz disks or network interfaces in a domU, use this, blah blah." Actually setting the option there is not a good idea, because people can still have GRUB_CMDLINE_XEN_DEFAULT set in e.g. /etc/default/grub, so that would override and damage things. Other option is to add a patch to drag the defaults in the upstream code from 32 to 64, including documentation etc. Sorry for the earlier confusion, Hans From hans at knorrie.org Sun Jan 7 18:36:40 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Sun, 7 Jan 2018 19:36:40 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <20180107090507.GC6604@gavran.carpriv.carnet.hr> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> Message-ID: <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> On 01/07/2018 10:05 AM, Valentin Vidic wrote: > On Sat, Jan 06, 2018 at 11:17:00PM +0100, Hans van Kranenburg wrote: >> I agree that the upstream default, 32 is quite low. This is indeed a >> configuration issue. I myself ran into this years ago with a growing >> number of domUs and network interfaces in use. We have been using >> gnttab_max_nr_frames=128 for a long time already instead. >> >> I was tempted to reassign src:xen, but in the meantime, this option has >> already been removed again, so this bug does not apply to unstable >> (well, as soon as we get something new in there) any more (as far as I >> can see quickly now). >> >> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=18b1be5e324bcbe2f10898b116db641d404b3d30 > > It does not seem to be removed but increased the default from 32 to 64? Ehm, yes you are correct. I was misreading and mixing up things. Let's try again... The referenced commit is talking about removal of the obsolete gnttab_max_nr_frames from the documentation, so not related. >> Including a better default for gnttab_max_nr_frames in the grub config >> in the debian xen package in stable sounds reasonable from a best >> practices point of view. So, that's gnttab_max_frames, not gnttab_max_nr_frames... I was reading out loud from my old Jessie dom0 grub config. >> But, I would be interested in learning more about the relation with >> block mq although. Does using newer linux kernels (like from >> stretch-backports) for the domU always put a bigger strain on this? Or, >> is it just related to the overall number of network devices and block >> devices you are adding to your domUs in your specific own situation, and >> did you just trip over the default limit? > > After upgrading the domU and dom0 from jessie to stretch on a big postgresql > database server (50 VCPUs, 200GB RAM) it starting freezing very soon > after boot as posted there here: > > https://lists.xen.org/archives/html/xen-users/2017-07/msg00057.html > > It did not have these problems while running jessie versions of the > hypervisor and the kernels. The problem seems to be related to the > number of CPUs used, as smaller domUs with a few VCPUs did not hang > like this. Could it be that large number of VCPUs -> more queues in > Xen mq driver -> faster exhaustion of allocated pages? That exactly seems to be the case yes. Maybe this is also one of the reasons that the default max was increased in Xen. "xen/blkback: make pool of persistent grants and free pages per-queue" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4bf0065b7251afb723a29b2fd58f7c38f8ce297 Recently a tool was added to "dump guest grant table info". You could see if it compiles on the 4.8 source and see if it works? Would be interesting to get some idea about how high or low these numbers are in different scenarios. I mean, I'm using 128, you 256, and we even don't know if the actual value is maybe just above 32? :] https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=df36d82e3fc91bee2ff1681fd438c815fa324b6a If this is something users are going to run into while not doing more unusual things like having dozens of vcpus or network interfaces, then changing the default could prevent hours of frustration and debugging for them. The least invasive option is to add the option to the documentation of GRUB_CMDLINE_XEN_DEFAULT in /etc/default/grub.d/xen.cfg like "If you have more than xyz disks or network interfaces in a domU, use this, blah blah." Actually setting the option there is not a good idea, because people can still have GRUB_CMDLINE_XEN_DEFAULT set in e.g. /etc/default/grub, so that would override and damage things. Other option is to add a patch to drag the defaults in the upstream code from 32 to 64, including documentation etc. Sorry for the earlier confusion, Hans From Valentin.Vidic at CARNet.hr Mon Jan 8 12:38:20 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Mon, 8 Jan 2018 13:38:20 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> Message-ID: <20180108123820.GG6604@gavran.carpriv.carnet.hr> On Sun, Jan 07, 2018 at 07:36:40PM +0100, Hans van Kranenburg wrote: > Recently a tool was added to "dump guest grant table info". You could > see if it compiles on the 4.8 source and see if it works? Would be > interesting to get some idea about how high or low these numbers are in > different scenarios. I mean, I'm using 128, you 256, and we even don't > know if the actual value is maybe just above 32? :] > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=df36d82e3fc91bee2ff1681fd438c815fa324b6a The diag tool does not build inside xen-4.8: xen-diag.c: In function ?gnttab_query_size_func?: xen-diag.c:50:10: error: implicit declaration of function ?xc_gnttab_query_size? [-Werror=implicit-function-declaration] rc = xc_gnttab_query_size(xch, &query); ^~~~~~~~~~~~~~~~~~~~ but I think the same info is available in the thread on xen-devel: https://www.mail-archive.com/xen-devel at lists.xen.org/msg116910.html When the domU hangs crash reports nr_grant_frames=32. After increasing the gnttab_max_frames=256 the domU reports using nr_grant_frames=59. So the new default of gnttab_max_frames=64 might be a bit close to 59, but I suppose 128 would be just as safe as 256 I currently use (if you prefer 128). > If this is something users are going to run into while not doing more > unusual things like having dozens of vcpus or network interfaces, then > changing the default could prevent hours of frustration and debugging > for them. Yes, the failure case is quite nasty, as the domU just hangs without even suggesting grant frames might be the problem. Not sure if domU can detect this situation at all? Anyway, if the value cannot be increased, the situation should at least be mentioned in the NEWS.Debian of the xen package. -- Valentin From Valentin.Vidic at CARNet.hr Mon Jan 8 12:38:20 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Mon, 8 Jan 2018 13:38:20 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> Message-ID: <20180108123820.GG6604@gavran.carpriv.carnet.hr> On Sun, Jan 07, 2018 at 07:36:40PM +0100, Hans van Kranenburg wrote: > Recently a tool was added to "dump guest grant table info". You could > see if it compiles on the 4.8 source and see if it works? Would be > interesting to get some idea about how high or low these numbers are in > different scenarios. I mean, I'm using 128, you 256, and we even don't > know if the actual value is maybe just above 32? :] > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=df36d82e3fc91bee2ff1681fd438c815fa324b6a The diag tool does not build inside xen-4.8: xen-diag.c: In function ?gnttab_query_size_func?: xen-diag.c:50:10: error: implicit declaration of function ?xc_gnttab_query_size? [-Werror=implicit-function-declaration] rc = xc_gnttab_query_size(xch, &query); ^~~~~~~~~~~~~~~~~~~~ but I think the same info is available in the thread on xen-devel: https://www.mail-archive.com/xen-devel at lists.xen.org/msg116910.html When the domU hangs crash reports nr_grant_frames=32. After increasing the gnttab_max_frames=256 the domU reports using nr_grant_frames=59. So the new default of gnttab_max_frames=64 might be a bit close to 59, but I suppose 128 would be just as safe as 256 I currently use (if you prefer 128). > If this is something users are going to run into while not doing more > unusual things like having dozens of vcpus or network interfaces, then > changing the default could prevent hours of frustration and debugging > for them. Yes, the failure case is quite nasty, as the domU just hangs without even suggesting grant frames might be the problem. Not sure if domU can detect this situation at all? Anyway, if the value cannot be increased, the situation should at least be mentioned in the NEWS.Debian of the xen package. -- Valentin From kehufuwu at mail4.caiwuziyouren.com.cn Tue Jan 9 01:41:18 2018 From: kehufuwu at mail4.caiwuziyouren.com.cn (=?UTF-8?B?6LSi5Yqh6Ieq55Sx5Lq6?=) Date: Tue, 9 Jan 2018 09:41:18 +0800 (CST) Subject: [Pkg-xen-devel] =?utf-8?b?5ZCs5Yiw5LqG6L+Z5Liq6LWaMTAwMOS4hw==?= =?utf-8?b?55qE55yf55u477yM5oiR5LiA5oqK5pKV5LqG5Yia5Lmw55qE56aP5Yip5b2p?= =?utf-8?b?56WoKEFEKQ==?= Message-ID: <724863774.139651.1515462078444.JavaMail.javamailuser@localhost> An HTML attachment was scrubbed... URL: From hans at knorrie.org Tue Jan 9 22:05:45 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Tue, 9 Jan 2018 23:05:45 +0100 Subject: [Pkg-xen-devel] Xen packaging in Debian - Progress update In-Reply-To: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> References: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> Message-ID: <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> Hi, On 12/22/2017 02:01 AM, Hans van Kranenburg wrote: > To: Debian xen and kernel team list, Ian Jackson I'm replying to my own email, since there has not been a reply on the lists to it yet. For Ian Jackson: There's a question for you below (section "Moving packaging repository"), can you please answer that. == Whaaaaat's happening? (skip this section if you're busy) == Three weeks ago, when I started working on this, I didn't remotely know what would happen on Jan 3, but I like the rollercoaster ride. In the past days: * ...I've been working to get the packaging moved on from 4.9 to Xen 4.10. * ...I could help the kernel team a bit with handling xen-related regression bugs that were reported on the updated linux packages. * ...replied to a few other open Xen bugs. * Moritz from the security team mailed me like "Hey! Did you get any response on that email? What's gonna happen to xen?" and I told him what was going on and that I'd like to help wherever I can. * ...the #debian-xen IRC channel on OFTC has become active again, others have been joining and offering more help, and we're discussing all kind of things, about packaging, but also about upgrade tactics for any size Xen cluster we're managing ourselves. == Security update for Stretch == On IRC I got some questions about the already earlier released XSA patches, which still aren't in Stretch. Question for security team: If you want to have it, I've prepared an update for in the mean time. [0] [1] [2]. I'm not a Maintainer yet, but at least I have some GPG signatures of Debian Developers now. ;] == Xen 4.10 == We're still all looking at upstream to find out what they're going to do in the next days. My gut feeling is that a not-neglectible part of users is looking into upgrading to Xen 4.10 and Linux 4.14 in the domU. It would be really great if Debian could have Xen 4.10 in testing and stretch-backports. So, in the meantime I'm trying to get a proper Xen 4.10 package in order for unstable. The build doesn't work completely yet, but if there's a dpkg-shlibdeps expert around, maybe you can help. More info on IRC. In general, If someone with more intimate knowledge of Xen can help review the changes, always welcome, as well as beta-testers for new packages. == Moving packaging repository == It makes sense to get the cleaned up packaging code moved to a new Debian Xen team owned repo at the new Debian Gitlab hosting. Ian: Can you please ACK that it's ok if we go on with this and take ownership to get it set up? Thanks. == Thanks for your time == Regards, Hans van Kranenburg [0] https://github.com/knorrie/debian-xen/commit/d3922c423010894d5badfc5381a7312b90715cbf [1] https://github.com/knorrie/debian-xen/releases/tag/debian%2F4.8.2%2Bxsa245-0%2Bdeb9u2 [2] https://syrinx.knorrie.org/~knorrie/xen/stretch-security/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ssgelm at gmail.com Wed Jan 10 02:02:15 2018 From: ssgelm at gmail.com (Stephen Gelman) Date: Tue, 9 Jan 2018 20:02:15 -0600 Subject: [Pkg-xen-devel] Xen packaging in Debian - Progress update In-Reply-To: <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> References: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> Message-ID: <140B8718-8340-45FD-B2CC-9CD585C4F079@gmail.com> Hi all, Thanks for sending this update Hans. I too am interested in helping out with xen packaging. I am trying to dig into the dpkg-shlibdeps issues - I built it successfully on one box but haven?t been able to reproduce. Either way, I will plan to hang around in IRC to help where I can. Stephen > On Jan 9, 2018, at 4:05 PM, Hans van Kranenburg wrote: > > Hi, > > On 12/22/2017 02:01 AM, Hans van Kranenburg wrote: >> To: Debian xen and kernel team list, Ian Jackson > > I'm replying to my own email, since there has not been a reply on the > lists to it yet. > > For Ian Jackson: There's a question for you below (section "Moving > packaging repository"), can you please answer that. > > == Whaaaaat's happening? (skip this section if you're busy) == > > Three weeks ago, when I started working on this, I didn't remotely know > what would happen on Jan 3, but I like the rollercoaster ride. > > In the past days: > * ...I've been working to get the packaging moved on from 4.9 to Xen 4.10. > * ...I could help the kernel team a bit with handling xen-related > regression bugs that were reported on the updated linux packages. > * ...replied to a few other open Xen bugs. > * Moritz from the security team mailed me like "Hey! Did you get any > response on that email? What's gonna happen to xen?" and I told him what > was going on and that I'd like to help wherever I can. > * ...the #debian-xen IRC channel on OFTC has become active again, others > have been joining and offering more help, and we're discussing all kind > of things, about packaging, but also about upgrade tactics for any size > Xen cluster we're managing ourselves. > > == Security update for Stretch == > > On IRC I got some questions about the already earlier released XSA > patches, which still aren't in Stretch. > > Question for security team: If you want to have it, I've prepared an > update for in the mean time. [0] [1] [2]. I'm not a Maintainer yet, but > at least I have some GPG signatures of Debian Developers now. ;] > > == Xen 4.10 == > > We're still all looking at upstream to find out what they're going to do > in the next days. > > My gut feeling is that a not-neglectible part of users is looking into > upgrading to Xen 4.10 and Linux 4.14 in the domU. It would be really > great if Debian could have Xen 4.10 in testing and stretch-backports. > > So, in the meantime I'm trying to get a proper Xen 4.10 package in order > for unstable. The build doesn't work completely yet, but if there's a > dpkg-shlibdeps expert around, maybe you can help. More info on IRC. > > In general, If someone with more intimate knowledge of Xen can help > review the changes, always welcome, as well as beta-testers for new > packages. > > == Moving packaging repository == > > It makes sense to get the cleaned up packaging code moved to a new > Debian Xen team owned repo at the new Debian Gitlab hosting. > > Ian: Can you please ACK that it's ok if we go on with this and take > ownership to get it set up? Thanks. > > == Thanks for your time == > > Regards, > Hans van Kranenburg > > [0] > https://github.com/knorrie/debian-xen/commit/d3922c423010894d5badfc5381a7312b90715cbf > > [1] > https://github.com/knorrie/debian-xen/releases/tag/debian%2F4.8.2%2Bxsa245-0%2Bdeb9u2 > > [2] https://syrinx.knorrie.org/~knorrie/xen/stretch-security/ > > _______________________________________________ > Pkg-xen-devel mailing list > Pkg-xen-devel at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xen-devel From debian at babilen5.org Wed Jan 10 07:54:13 2018 From: debian at babilen5.org (Wolodja Wentland) Date: Wed, 10 Jan 2018 07:54:13 +0000 Subject: [Pkg-xen-devel] Xen security update [was: Re: Xen packaging in Debian - Progress update] In-Reply-To: <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> References: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> Message-ID: <87373egndm.fsf@skade.home> Hans van Kranenburg writes: > == Security update for Stretch == > > On IRC I got some questions about the already earlier released XSA > patches, which still aren't in Stretch. It would be a lovely if a security upload that includes patches for the following XSAs could be prepared, given that many people will reboot their hypervisors these days: - https://xenbits.xen.org/xsa/advisory-248.html - https://xenbits.xen.org/xsa/advisory-249.html - https://xenbits.xen.org/xsa/advisory-250.html - https://xenbits.xen.org/xsa/advisory-251.html These are all single patches that apply cleanly to 4.8 (with some fuzz) and will have been deployed in locally built packages by many. Thanks for all your efforts! -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC From hans at knorrie.org Wed Jan 10 09:29:59 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Wed, 10 Jan 2018 10:29:59 +0100 Subject: [Pkg-xen-devel] Xen security update [was: Re: Xen packaging in Debian - Progress update] In-Reply-To: <87373egndm.fsf@skade.home> References: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> <87373egndm.fsf@skade.home> Message-ID: On 01/10/2018 08:54 AM, Wolodja Wentland wrote: > Hans van Kranenburg writes: > >> == Security update for Stretch == >> >> On IRC I got some questions about the already earlier released XSA >> patches, which still aren't in Stretch. > > It would be a lovely if a security upload that includes patches for the > following XSAs could be prepared, given that many people will reboot > their hypervisors these days: > > - https://xenbits.xen.org/xsa/advisory-248.html > - https://xenbits.xen.org/xsa/advisory-249.html > - https://xenbits.xen.org/xsa/advisory-250.html > - https://xenbits.xen.org/xsa/advisory-251.html > > These are all single patches that apply cleanly to 4.8 (with some fuzz) > and will have been deployed in locally built packages by many. Yes, that's what that whole section was about. See the links in my previous message. Got reply from security team: "Thanks, I'll get back to you end of week." Hans From hans at knorrie.org Wed Jan 10 10:10:09 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Wed, 10 Jan 2018 11:10:09 +0100 Subject: [Pkg-xen-devel] Xen packaging in Debian - Progress update In-Reply-To: <140B8718-8340-45FD-B2CC-9CD585C4F079@gmail.com> References: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> <140B8718-8340-45FD-B2CC-9CD585C4F079@gmail.com> Message-ID: <5A55E681.808@knorrie.org> On 10/01/2018 03:02, Stephen Gelman wrote: > > Thanks for sending this update Hans. I too am interested in helping > out with xen packaging. I am trying to dig into the dpkg-shlibdeps > issues - I built it successfully on one box but haven?t been able to > reproduce. Either way, I will plan to hang around in IRC to help > where I can. Yay, welcome aboard! Hans From ijackson at chiark.greenend.org.uk Wed Jan 10 17:14:15 2018 From: ijackson at chiark.greenend.org.uk (Ian Jackson) Date: Wed, 10 Jan 2018 17:14:15 +0000 Subject: [Pkg-xen-devel] Xen packaging in Debian - Progress update In-Reply-To: <5A55E681.808@knorrie.org> References: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> <140B8718-8340-45FD-B2CC-9CD585C4F079@gmail.com> <5A55E681.808@knorrie.org> Message-ID: <23126.18919.722998.435055@chiark.greenend.org.uk> Hi. FTR I am reading these mails and talking to Hans on irc occasionally. I work on Xen in Debian for Citrix, as part of the Xen upstream team,[1] and of course we have been ... rather distracted. I am really glad to see other people taking an interest in Xen packaging in Debian. Ian. [1] One of my hats is a member of security at xen -- Ian Jackson These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. From plugwash at p10link.net Thu Jan 11 17:59:05 2018 From: plugwash at p10link.net (peter green) Date: Thu, 11 Jan 2018 17:59:05 +0000 Subject: [Pkg-xen-devel] Bug#853710: xen: ftbfs with GCC-7 References: Message-ID: > I think the compiler is simply wrong to complain about this. If you are going to build with options like "-Wall -Werror" then you have to expect the compiler to be bitchy. You should be able to make this particular warning non-fatal by adding -Wno-error=int-in-bool-context -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at knorrie.org Thu Jan 11 21:42:43 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Thu, 11 Jan 2018 22:42:43 +0100 Subject: [Pkg-xen-devel] Bug#853710: Bug#853710: xen: ftbfs with GCC-7 In-Reply-To: References: Message-ID: <5A57DA53.1010404@knorrie.org> Hey, On 11/01/2018 18:59, peter green wrote: >> I think the compiler is simply wrong to complain about this. > If you are going to build with options like "-Wall -Werror" then you > have to expect the compiler to be bitchy. You should be able to make > this particular warning non-fatal by adding -Wno-error=int-in-bool-context Thanks for the help. First thing that's going to happen to Xen in Debian unstable is moving to Xen 4.10, which compiles fine with gcc-7. If I point my pbuilder (debian unstable) at the current package that's in the archive, it indeed explodes halfway: xenlockprof.c: In function 'main': xenlockprof.c:100:53: error: '%s' directive writing up to 39 bytes into a region of size between 17 and 37 [-Werror=format-overflow=] sprintf(name, "unknown type(%d) %d lock %s", data[j].type, ^~ xenlockprof.c:100:13: note: 'sprintf' output between 24 and 83 bytes into a destination of size 60 sprintf(name, "unknown type(%d) %d lock %s", data[j].type, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ data[j].idx, data[j].name); ~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors So, FWIW, I think we can close this case, since buster will definitely not ship with Xen 4.8 but newer. Thanks, Hans From hans at knorrie.org Thu Jan 11 22:01:46 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Thu, 11 Jan 2018 23:01:46 +0100 Subject: [Pkg-xen-devel] Bug#853710: Bug#853710: xen: ftbfs with GCC-7 In-Reply-To: <5A57DA53.1010404@knorrie.org> References: <5A57DA53.1010404@knorrie.org> Message-ID: <5A57DECA.5000806@knorrie.org> On 11/01/2018 22:42, Hans van Kranenburg wrote: > Hey, > > On 11/01/2018 18:59, peter green wrote: >>> I think the compiler is simply wrong to complain about this. >> If you are going to build with options like "-Wall -Werror" then you >> have to expect the compiler to be bitchy. You should be able to make >> this particular warning non-fatal by adding -Wno-error=int-in-bool-context > > Thanks for the help. > > First thing that's going to happen to Xen in Debian unstable is moving > to Xen 4.10, which compiles fine with gcc-7. > > If I point my pbuilder (debian unstable) at the current package that's > in the archive, it indeed explodes halfway: > > xenlockprof.c: In function 'main': > xenlockprof.c:100:53: error: '%s' directive writing up to 39 bytes into > a region of size between 17 and 37 [-Werror=format-overflow=] > sprintf(name, "unknown type(%d) %d lock %s", data[j].type, > ^~ > xenlockprof.c:100:13: note: 'sprintf' output between 24 and 83 bytes > into a destination of size 60 > sprintf(name, "unknown type(%d) %d lock %s", data[j].type, > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > data[j].idx, data[j].name); > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > cc1: all warnings being treated as errors Actually, this is a different error, which looks a bit like a buffer overflow type of thing? I'm not a C code compile hero (yet?), just started out helping on the Xen team. So maybe someone else can better comment on this specific thing. > So, FWIW, I think we can close this case, since buster will definitely > not ship with Xen 4.8 but newer. Or maybe we're allowed to close it when the new upload is being done, and you want to have it open until then? In that case there's no way it'll slip through. Just wanted to let know that during the preparations of upgrading the package to Xen 4.10 I have been able to build successfully targeting unstable so far. Thanks, Hans From hans at knorrie.org Fri Jan 12 00:34:10 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Fri, 12 Jan 2018 01:34:10 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <20180108123820.GG6604@gavran.carpriv.carnet.hr> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> <20180108123820.GG6604@gavran.carpriv.carnet.hr> Message-ID: <5A580282.8070306@knorrie.org> Hi, On 08/01/2018 13:38, Valentin Vidic wrote: > On Sun, Jan 07, 2018 at 07:36:40PM +0100, Hans van Kranenburg wrote: >> Recently a tool was added to "dump guest grant table info". You could >> see if it compiles on the 4.8 source and see if it works? Would be >> interesting to get some idea about how high or low these numbers are in >> different scenarios. I mean, I'm using 128, you 256, and we even don't >> know if the actual value is maybe just above 32? :] >> >> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=df36d82e3fc91bee2ff1681fd438c815fa324b6a > > The diag tool does not build inside xen-4.8: > > xen-diag.c: In function ?gnttab_query_size_func?: > xen-diag.c:50:10: error: implicit declaration of function ?xc_gnttab_query_size? [-Werror=implicit-function-declaration] > rc = xc_gnttab_query_size(xch, &query); > ^~~~~~~~~~~~~~~~~~~~ Too bad. :| > but I think the same info is available in the thread on xen-devel: > > https://www.mail-archive.com/xen-devel at lists.xen.org/msg116910.html Ah, great, didn't see that one yet. > When the domU hangs crash reports nr_grant_frames=32. After increasing > the gnttab_max_frames=256 the domU reports using nr_grant_frames=59. > > So the new default of gnttab_max_frames=64 might be a bit close to 59, > but I suppose 128 would be just as safe as 256 I currently use (if > you prefer 128). Is the 59 your lots-o-vcpu-monster? I just finished with the initial preparation of a Xen 4.10 package for unstable and have it running in my test environment. So, yay, I have xen-diag now. -# /usr/lib/xen-4.10/bin/xen-diag xen-diag: xen diagnostic utility Usage: xen-diag command [args] Commands: help display this help gnttab_query_size dump the current and max grant frames for -# /usr/lib/xen-4.10/bin/xen-diag gnttab_query_size 0 domid=0: nr_frames=1, max_nr_frames=64 That's a 10vcpu PVHv2 domU with two disks attached, running 4.14 guest kernel, which has only been booted up and is idling now. So, at least, nice to have some extra tooling available to help. >> If this is something users are going to run into while not doing more >> unusual things like having dozens of vcpus or network interfaces, then >> changing the default could prevent hours of frustration and debugging >> for them. > > Yes, the failure case is quite nasty, as the domU just hangs without > even suggesting grant frames might be the problem. Not sure if domU > can detect this situation at all? I can't comment on that, since I don't know. Anyone who does, please chime in. > Anyway, if the value cannot be increased, the situation should at least > be mentioned in the NEWS.Debian of the xen package. Since this has been reported multiple times already, and upstream has bumped it to 64, my verdict would be: * Bump default to 64 already like upstream did in a later version. * Properly document this issue in NEWS.Debian and also mention the option with documentation in the template grub config file, so there's a bigger chance users who run unusual big numbers of disks/nics/cpus/etc will find it. ...so we also better accomodate users who are using newer kernels in the domU with blk-mq, and prevent them from wasting too much time and getting frustrated for no reason. I wouldn't be comfortable with bumping it above the current latest greatest upstream default, since it would mean we would need to keep a patch in later versions. I'll prepare a patch to bump the default to 64 in 4.8, taking changes from the upstream patch. I probably have to ask upstream (Juergen Gross) why the commit that was referenced earlier bumps the default without mentioning it in the commit message. Since I just joined the Debian Xen team, I'll run anything I can come up with through the team to get it approved. We'll target the next Stretch stable update to get it in. Thanks, Hans From Valentin.Vidic at CARNet.hr Fri Jan 12 11:43:03 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Fri, 12 Jan 2018 12:43:03 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <5A580282.8070306@knorrie.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> <20180108123820.GG6604@gavran.carpriv.carnet.hr> <5A580282.8070306@knorrie.org> Message-ID: <20180112114303.GI2623@gavran.carpriv.carnet.hr> On Fri, Jan 12, 2018 at 01:34:10AM +0100, Hans van Kranenburg wrote: > Is the 59 your lots-o-vcpu-monster? Yes, that is the one with a larger vcpu count. > I just finished with the initial preparation of a Xen 4.10 package for > unstable and have it running in my test environment. Unrelated to this issue, but can you tell me if there is a way to mitigate Meltdown with the Xen 4.8 dom0/domU(PV) running stretch? > Since this has been reported multiple times already, and upstream has > bumped it to 64, my verdict would be: > > * Bump default to 64 already like upstream did in a later version. > * Properly document this issue in NEWS.Debian and also mention the > option with documentation in the template grub config file, so there's a > bigger chance users who run unusual big numbers of disks/nics/cpus/etc > will find it. > > ...so we also better accomodate users who are using newer kernels in the > domU with blk-mq, and prevent them from wasting too much time and > getting frustrated for no reason. > > I wouldn't be comfortable with bumping it above the current latest > greatest upstream default, since it would mean we would need to keep a > patch in later versions. > > I'll prepare a patch to bump the default to 64 in 4.8, taking changes > from the upstream patch. I probably have to ask upstream (Juergen Gross) > why the commit that was referenced earlier bumps the default without > mentioning it in the commit message. Thanks, 64 should be a good start. If there are still problems reported with that it can be reconsidered. -- Valentin From hans at knorrie.org Fri Jan 12 13:29:01 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Fri, 12 Jan 2018 14:29:01 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <20180112114303.GI2623@gavran.carpriv.carnet.hr> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> <20180108123820.GG6604@gavran.carpriv.carnet.hr> <5A580282.8070306@knorrie.org> <20180112114303.GI2623@gavran.carpriv.carnet.hr> Message-ID: <3d475455-5d5c-ccae-f5f2-b4d37b4b204b@knorrie.org> On 01/12/2018 12:43 PM, Valentin Vidic wrote: > On Fri, Jan 12, 2018 at 01:34:10AM +0100, Hans van Kranenburg wrote: >> Is the 59 your lots-o-vcpu-monster? > > Yes, that is the one with a larger vcpu count. Check. >> I just finished with the initial preparation of a Xen 4.10 package for >> unstable and have it running in my test environment. > > Unrelated to this issue, but can you tell me if there is a way to > mitigate Meltdown with the Xen 4.8 dom0/domU(PV) running stretch? There are no updates for the hypervisor itself yet that we can distribute in Debian. This is your starting point for information: https://xenbits.xen.org/xsa/advisory-254.html https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ So, 64-bit PV guests can attack the hypervisor and other guests. If you have untrusted PV guests the short term choices are to 1) convert them to HVM or 2) shield your hypervisor from them by following the instructions for the 'PV-in-PVH/HVM shim approach' (where currently for Xen 4.8 only PV-in-HVM is relevant). There's still a pending security update for Stretch to address the previous XSA (up to 251), and it seems best to piggyback on that put some guidance and information for users in there as well. If you use IRC, you can also join #debian-xen on OFTC if you want, to discuss things. There's a bunch of people there sharing information and strategies about what to do with their debian systems. >> Since this has been reported multiple times already, and upstream has >> bumped it to 64, my verdict would be: >> >> * Bump default to 64 already like upstream did in a later version. >> * Properly document this issue in NEWS.Debian and also mention the >> option with documentation in the template grub config file, so there's a >> bigger chance users who run unusual big numbers of disks/nics/cpus/etc >> will find it. >> >> ...so we also better accomodate users who are using newer kernels in the >> domU with blk-mq, and prevent them from wasting too much time and >> getting frustrated for no reason. >> >> I wouldn't be comfortable with bumping it above the current latest >> greatest upstream default, since it would mean we would need to keep a >> patch in later versions. >> >> I'll prepare a patch to bump the default to 64 in 4.8, taking changes >> from the upstream patch. I probably have to ask upstream (Juergen Gross) >> why the commit that was referenced earlier bumps the default without >> mentioning it in the commit message. > > Thanks, 64 should be a good start. If there are still problems > reported with that it can be reconsidered. Hans From christian.schwamborn at nswit.de Mon Jan 15 10:12:03 2018 From: christian.schwamborn at nswit.de (Christian Schwamborn) Date: Mon, 15 Jan 2018 11:12:03 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> Message-ID: <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> Hi Hans and Valentin, first of all: Thanks for your help and explanations, that is very helpfull. I was on vacation last week and couldn't answer right away. On 07.01.2018 19:36, Hans van Kranenburg wrote: > If this is something users are going to run into while not doing more > unusual things like having dozens of vcpus or network interfaces, then > changing the default could prevent hours of frustration and debugging > for them. As a reference: Dom0 is stretch. 0 root at zero:~# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 1961 2 r----- 407972.8 xaver-jessie 10 2048 2 -b---- 177520.8 ustrich-jessie 12 2048 2 -b---- 8555.9 ourea-stretch 14 8192 2 -b---- 167352.7 arriba 17 4096 2 -b---- 5108.3 All DomU's have one network interface on a bridge. xaver-jessie has 5 block devices (phys, lvm) ustrich-jessie has 4 block devices (phys, lvm) ourea-stretch has 16 block devices (phys, lvm) arriba has just one (phys, lvm) and is a hvm windows system As you can see, nothing crazy with lots of vcpus or network interfaces. The crashing (freezing) DomU was ourea-stretch, which is the one with the most load (smb, some web services, cal/card dav, psql, ldap, postfix, cyrus ...). As mentioned, the freezes stopped after using the backports kernel, nothing else changed. I was desperate at that time to get this new installed system to work and frankly stopped all planed updates to stretch on other systems at that point until I know what is going on. Is there a easy way to get/monitor the used 'grants' frames? As I understand it, the xen-diag tool you mentioned doesn't compile in xen 4.8? Christian From christian.schwamborn at nswit.de Mon Jan 15 10:12:03 2018 From: christian.schwamborn at nswit.de (Christian Schwamborn) Date: Mon, 15 Jan 2018 11:12:03 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> Message-ID: <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> Hi Hans and Valentin, first of all: Thanks for your help and explanations, that is very helpfull. I was on vacation last week and couldn't answer right away. On 07.01.2018 19:36, Hans van Kranenburg wrote: > If this is something users are going to run into while not doing more > unusual things like having dozens of vcpus or network interfaces, then > changing the default could prevent hours of frustration and debugging > for them. As a reference: Dom0 is stretch. 0 root at zero:~# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 1961 2 r----- 407972.8 xaver-jessie 10 2048 2 -b---- 177520.8 ustrich-jessie 12 2048 2 -b---- 8555.9 ourea-stretch 14 8192 2 -b---- 167352.7 arriba 17 4096 2 -b---- 5108.3 All DomU's have one network interface on a bridge. xaver-jessie has 5 block devices (phys, lvm) ustrich-jessie has 4 block devices (phys, lvm) ourea-stretch has 16 block devices (phys, lvm) arriba has just one (phys, lvm) and is a hvm windows system As you can see, nothing crazy with lots of vcpus or network interfaces. The crashing (freezing) DomU was ourea-stretch, which is the one with the most load (smb, some web services, cal/card dav, psql, ldap, postfix, cyrus ...). As mentioned, the freezes stopped after using the backports kernel, nothing else changed. I was desperate at that time to get this new installed system to work and frankly stopped all planed updates to stretch on other systems at that point until I know what is going on. Is there a easy way to get/monitor the used 'grants' frames? As I understand it, the xen-diag tool you mentioned doesn't compile in xen 4.8? Christian From Valentin.Vidic at CARNet.hr Mon Jan 15 10:59:19 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Mon, 15 Jan 2018 11:59:19 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> Message-ID: <20180115105919.GP2623@gavran.carpriv.carnet.hr> On Mon, Jan 15, 2018 at 11:12:03AM +0100, Christian Schwamborn wrote: > Is there a easy way to get/monitor the used 'grants' frames? As I understand > it, the xen-diag tool you mentioned doesn't compile in xen 4.8? I just gave it another try and after modifying xen-diag.c a bit to work with 4.8 here is what I get: # ./xen-diag gnttab_query_size 0 domid=0: nr_frames=4, max_nr_frames=256 # ./xen-diag gnttab_query_size 1 domid=1: nr_frames=11, max_nr_frames=256 # ./xen-diag gnttab_query_size 0 domid=0: nr_frames=4, max_nr_frames=256 # ./xen-diag gnttab_query_size 1 domid=1: nr_frames=11, max_nr_frames=256 # ./xen-diag gnttab_query_size 5 domid=5: nr_frames=11, max_nr_frames=256 so currently at 11, not high at all. Attaching a patch for stretch xen package if you want to check your hosts. -- Valentin -------------- next part -------------- A non-text attachment was scrubbed... Name: xen-diag.patch Type: text/x-diff Size: 3760 bytes Desc: not available URL: From Valentin.Vidic at CARNet.hr Mon Jan 15 10:59:19 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Mon, 15 Jan 2018 11:59:19 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> Message-ID: <20180115105919.GP2623@gavran.carpriv.carnet.hr> On Mon, Jan 15, 2018 at 11:12:03AM +0100, Christian Schwamborn wrote: > Is there a easy way to get/monitor the used 'grants' frames? As I understand > it, the xen-diag tool you mentioned doesn't compile in xen 4.8? I just gave it another try and after modifying xen-diag.c a bit to work with 4.8 here is what I get: # ./xen-diag gnttab_query_size 0 domid=0: nr_frames=4, max_nr_frames=256 # ./xen-diag gnttab_query_size 1 domid=1: nr_frames=11, max_nr_frames=256 # ./xen-diag gnttab_query_size 0 domid=0: nr_frames=4, max_nr_frames=256 # ./xen-diag gnttab_query_size 1 domid=1: nr_frames=11, max_nr_frames=256 # ./xen-diag gnttab_query_size 5 domid=5: nr_frames=11, max_nr_frames=256 so currently at 11, not high at all. Attaching a patch for stretch xen package if you want to check your hosts. -- Valentin -------------- next part -------------- A non-text attachment was scrubbed... Name: xen-diag.patch Type: text/x-diff Size: 3760 bytes Desc: not available URL: From Valentin.Vidic at CARNet.hr Mon Jan 15 11:07:39 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Mon, 15 Jan 2018 12:07:39 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> Message-ID: <20180115110739.GQ2623@gavran.carpriv.carnet.hr> On Mon, Jan 15, 2018 at 11:12:03AM +0100, Christian Schwamborn wrote: > Is there a easy way to get/monitor the used 'grants' frames? As I understand > it, the xen-diag tool you mentioned doesn't compile in xen 4.8? Here is a status from another host: domid=0: nr_frames=4, max_nr_frames=256 domid=487: nr_frames=6, max_nr_frames=256 domid=488: nr_frames=5, max_nr_frames=256 domid=489: nr_frames=4, max_nr_frames=256 domid=490: nr_frames=6, max_nr_frames=256 domid=491: nr_frames=7, max_nr_frames=256 domid=492: nr_frames=4, max_nr_frames=256 domid=493: nr_frames=4, max_nr_frames=256 domid=494: nr_frames=29, max_nr_frames=256 domid=495: nr_frames=4, max_nr_frames=256 domid=496: nr_frames=4, max_nr_frames=256 domid=497: nr_frames=5, max_nr_frames=256 domid=498: nr_frames=4, max_nr_frames=256 domid=499: nr_frames=4, max_nr_frames=256 domid=500: nr_frames=4, max_nr_frames=256 domid=501: nr_frames=4, max_nr_frames=256 domid=503: nr_frames=5, max_nr_frames=256 domid=572: nr_frames=13, max_nr_frames=256 domid=575: nr_frames=7, max_nr_frames=256 Most of the hosts have older kernels and nr_frames < 10. And than 494 has a stretch kernel and only 4 vcpus but is quite close to the current default of 32. Maybe it just depends on the amount of disk IO? -- Valentin From Valentin.Vidic at CARNet.hr Mon Jan 15 11:07:39 2018 From: Valentin.Vidic at CARNet.hr (Valentin Vidic) Date: Mon, 15 Jan 2018 12:07:39 +0100 Subject: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64 In-Reply-To: <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> References: <20171117063920.thcte5kbejvcbnw4@gavran.carpriv.carnet.hr> <1515247706.3305.25.camel@debian.org> <20180106142356.GA6604@gavran.carpriv.carnet.hr> <1515251501.3305.29.camel@debian.org> <71456584-7e1a-1f59-be9a-8157f7d970b4@knorrie.org> <20180107090507.GC6604@gavran.carpriv.carnet.hr> <3d41182b-9b96-22c4-e63b-779c09efa114@knorrie.org> <746a4a46-9577-1fcb-8e22-baadd4f0c574@nswit.de> Message-ID: <20180115110739.GQ2623@gavran.carpriv.carnet.hr> On Mon, Jan 15, 2018 at 11:12:03AM +0100, Christian Schwamborn wrote: > Is there a easy way to get/monitor the used 'grants' frames? As I understand > it, the xen-diag tool you mentioned doesn't compile in xen 4.8? Here is a status from another host: domid=0: nr_frames=4, max_nr_frames=256 domid=487: nr_frames=6, max_nr_frames=256 domid=488: nr_frames=5, max_nr_frames=256 domid=489: nr_frames=4, max_nr_frames=256 domid=490: nr_frames=6, max_nr_frames=256 domid=491: nr_frames=7, max_nr_frames=256 domid=492: nr_frames=4, max_nr_frames=256 domid=493: nr_frames=4, max_nr_frames=256 domid=494: nr_frames=29, max_nr_frames=256 domid=495: nr_frames=4, max_nr_frames=256 domid=496: nr_frames=4, max_nr_frames=256 domid=497: nr_frames=5, max_nr_frames=256 domid=498: nr_frames=4, max_nr_frames=256 domid=499: nr_frames=4, max_nr_frames=256 domid=500: nr_frames=4, max_nr_frames=256 domid=501: nr_frames=4, max_nr_frames=256 domid=503: nr_frames=5, max_nr_frames=256 domid=572: nr_frames=13, max_nr_frames=256 domid=575: nr_frames=7, max_nr_frames=256 Most of the hosts have older kernels and nr_frames < 10. And than 494 has a stretch kernel and only 4 vcpus but is quite close to the current default of 32. Maybe it just depends on the amount of disk IO? -- Valentin From hans at knorrie.org Tue Jan 16 17:47:20 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Tue, 16 Jan 2018 18:47:20 +0100 Subject: [Pkg-xen-devel] Xen packaging in Debian - Progress update In-Reply-To: <23126.18919.722998.435055@chiark.greenend.org.uk> References: <1f1ee4cb-bbda-e9f4-2d05-c5bc95f6d6b9@knorrie.org> <98e313ea-6a41-8b24-9a48-709214e7f18d@knorrie.org> <140B8718-8340-45FD-B2CC-9CD585C4F079@gmail.com> <5A55E681.808@knorrie.org> <23126.18919.722998.435055@chiark.greenend.org.uk> Message-ID: <7136f45b-01e8-8204-1f9f-5dfee7a1a14f@knorrie.org> Hi Ian, On 01/10/2018 06:14 PM, Ian Jackson wrote: > > FTR I am reading these mails and talking to Hans on irc occasionally. > > I work on Xen in Debian for Citrix, as part of the Xen upstream team,[1] > and of course we have been ... rather distracted. I am really glad to > see other people taking an interest in Xen packaging in Debian. Do you have any indication about when you will available again to attend to the Debian team for a bit? When I arrived end December it was like I walked into someone elses house, while the front door was fully open and no one home. After a few weeks and also having new people visiting this is starting to feel a bit uncomfortable, sitting on the couch, looking at each other... I suspect you have some kind of idea in your head already about where you want to go with the 4.8 situation in Debian Stable. So, it could at least be helpful to share some info like "Hey guys, I'll be around then-and-then, in the meantime please RTFM A B and C, because that's the direction it will be heading in, oh, and if you could do D E F also, then we can hit the ground running." Thanks, Hans From juliana-secretariafazenda46976 at notafiscal-fazenda207.is-a-chef.com Wed Jan 24 17:15:53 2018 From: juliana-secretariafazenda46976 at notafiscal-fazenda207.is-a-chef.com (juliana-secretariafazenda46976 at notafiscal-fazenda207.is-a-chef.com) Date: Wed, 24 Jan 2018 17:15:53 +0000 Subject: [Pkg-xen-devel] =?UTF-8?Q?Gera=E7=E3o_de_Nota_Fiscal?= Message-ID: Gera??o de Nota FiscalPrezado(a)Foi gerada uma Nota Fiscal 10455689419713584 em nosso sistema, e voc? est?vinculado com o papel de Prestador.Caso deseje acess?-la favor acessar o arquivo em anexo.Juliana HorbachSecret?rio de Fazenda n_0761416006809365387318617471588564706407097924562303164811060826207948757 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: NF_239717287237947923973984_927398738467673.html Type: application/octet-stream Size: 301 bytes Desc: not available URL: From hans at knorrie.org Mon Jan 29 23:54:49 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Tue, 30 Jan 2018 00:54:49 +0100 Subject: [Pkg-xen-devel] Xen 4.10 for Debian experimental Message-ID: <4ecb22ea-400b-ebb0-50a0-eae0259fd3f4@knorrie.org> Hi Ian, can you please review and sponsor the upload of a first Xen 4.10 package to experimental? The work which has been done to arrive at this point from the previous 4.8 packages is visible at: https://salsa.debian.org/xen-team/debian-xen/commits/master The only commit which is not in master yet is the actual package release: https://salsa.debian.org/xen-team/debian-xen/commit/7f8ce30800d9a29b3f4a9ad0a88e18c02dd65212 The source package built from that commit, and signed with my GPG key, is available at: https://syrinx.knorrie.org/~knorrie/xen/ If the package gets accepted, I'll merge that commit, and put a tag on it. ---- >8 ---- The current state of the package is "Step 1. Make it work". Besides fixing everything that was needed to make the package build and do useful things after changing to 4.10 upstream, no further changes have been introduced yet. However, there are already a bunch of ideas floating around and being worked on for "Step 2. Make it beautiful" by various people, like reviewing the init scripts, think about needed qemu changes, cleanups (e.g. old xm related stuff), better support for driver domains, command line completion for xl, thinking about what would be needed to support live patching in Debian etc... I guess that the main next hurdle to get a new package in unstable is to align with the Debian qemu team for a transition plan to get qemu adjusted, so HVM can also be used again? Also, as can be seen above, I moved the git repository I was working in to Debian Salsa, since I haven't seen any objection to my previous emails on the list with the proposal to do so. In a few minutes, I'll send a separate mail with some thoughts about how to use the shiny new tools with the team. Thanks, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hans at knorrie.org Mon Jan 29 23:55:15 2018 From: hans at knorrie.org (Hans van Kranenburg) Date: Tue, 30 Jan 2018 00:55:15 +0100 Subject: [Pkg-xen-devel] Debian Xen Team organization Message-ID: Hi, Instead of typing everything here, I brain-dumped my initial thoughts into the gitlab wiki of the project: \o/ https://salsa.debian.org/xen-team/debian-xen/wikis/home Have fun, Hans From ian.jackson at eu.citrix.com Tue Jan 30 11:06:50 2018 From: ian.jackson at eu.citrix.com (Ian Jackson) Date: Tue, 30 Jan 2018 11:06:50 +0000 Subject: [Pkg-xen-devel] Xen 4.10 for Debian experimental In-Reply-To: <4ecb22ea-400b-ebb0-50a0-eae0259fd3f4@knorrie.org> References: <4ecb22ea-400b-ebb0-50a0-eae0259fd3f4@knorrie.org> Message-ID: <23152.20938.767704.874078@mariner.uk.xensource.com> Hans van Kranenburg writes ("Xen 4.10 for Debian experimental"): > can you please review and sponsor the upload of a first Xen 4.10 package > to experimental? Sure. I imagine I will get to this RSN. FYI, please CC my personal email address ijackson at chiark.greenend.org.uk. Although I work on Debian's Xen package on work time, my Citrix corporate email does not work sufficiently well so messages should go to both. Ian.